Metodika přechodu na Open Source. Příručka pro management organizací a správce ICT

Metodika přechodu na Open Source Příručka pro management organizací a správce ICT

Poradenské centrum pro podporu implementace opensource software Praha 2008

v. 1.1

Informace obsažené v tomto materiálů zohledňují názory a zkušenosti tvůrců. Vzhledem k rychlému vývoji informačních technologií se nedá zaručit nadčasovost uvedených informací. V případě, že v textu jsou jmenovány produkty, firmy nebo značky to neznamená, že jsou doporučovány nebo protěžovány.

Konkrétní nasazení vždy záleží na uživateli, jeho

možnostech a dispozicích. Institut pro informační společnost nenese žádnou zodpovědnost za škody způsobené instalací, testováním nebo jiným užíváním uvedených produktů a návodů. Obchodní známky užité v tomto dokumentu jsou vlastnictvím příslušných organizací. Institut pro informační společnost není ve spojení s uvedenými organizacemi. Institut pro informační společnost, o.s., je neziskovou organizací, která v České republice působí od roku 2005. Mezi hlavní cíle Institutu pro informační společnost patří iniciování a podpora vzájemné spolupráce mezi oborovými subjekty, tvarování a zlepšování podmínek pro rozvoj informační společnosti, pomoc znevýhodněným skupinám a boj za ochranu duševního vlastnictví a proti počítačovému pirátství. IPIS upřednostňuje osvětovou a vzdělávací činnost před represí.

Institut pro informační společnost, o.s. Poradenské centrum opensource Freyova 27 190 00 Praha 9 www.vasemoznosti.cz

Tato metodika vznikla pro účely projektu, který je spolufinancován prostředky Evropského sociálního fondu a státním rozpočtem ČR.

2

Obsah 1. Úvod

5

1.1. Zkratky a použitá terminologie

5

1.2. Typografické konvence

5

1.3. Cílová skupina

5

1.4. Cíl dokumentu

5

2. Stručný přehled

7

3. Metodika

9

4. Manažerská příručka

11

4.1. Přehled migrace

11

4.2. Lidské zdroje

15

4.3. Užitečné postřehy

17

5. Technická příručka

20

5.1. Referenční architektura

20

5.1.1. Generická architektura

20

5.1.2. Základní referenční architektura

23

5.2. Funkční skupiny

24

5.2.1. Primární skupiny

24

5.2.2. Podvojné skupiny

24

5.3. Resumé referenčního modelu

25

5.3.1. Pracovní stanice

26

5.3.2. Servery

28

5.4. Aplikace pro primární skupinu

29

5.4.1. Kancelářské balíky

30

5.4.2. Poštovní aplikace

32

5.4.3. Kalendář a groupware

34

5.4.4.Webové služby

35

5.4.5. Správa dokumentů

36

5.4.6. Databáze

37

5.5. Aplikace – podskupiny

38

5.5.1. Operační systém

38

5.5.2. Uživatelská rozhraní

40

5.5.3. Bezpečnost

40

5.5.4. Virtuální osobní sítě

42

5.5.5.Řízení

42

5.5.6. Backup a recovery

48

5.5.7. Jiné služby

48

3

6. Migrace aplikací – přehled

52

6.1. Scénář č. 1 – Windows

55

6.1.1. Plánování migrace

55

6.1.2. Oblasti působnosti

55

6.1.3. Obecné požadavky

57

6.1.4. Migrace prostředí operačního systému

62

6.1.5. Migrace aplikací na straně serveru

70

6.1.6. Image maps na straně serveru

70

6.1.7. Migrace pracovní stanice na OSS

78

6.2. Scénář č. 2 – Unix

86

6.3. Scénář č. 3 – Mainframe

88

6.4. Scénář č. 4 – Tenký klient

88

7. Přílohy

90

8. Užitečné odkazy a literatura

92

4

1. Úvod 1.1. Zkratky a použitá terminologie Ve většině případů je zkratka uvedena v plném znění při prvním použití. Seznam všech použitých zkratek je pak uveden v příloze tohoto dokumentu. Termíny Opensource software a Free Software mají svá specifika a zastánce. V tomto dokumentu je při použití termínu Open Source Software nebo zkratky OSS myšleno užití software dle vlastností, které jsou zahrnuty jak v OSS, tak Free Software. Pro detailní rozbor těchto termínů je možné navštívit stránky www.gnu.org/philosophy/categories.html a nebo www.opensource.org. Administrátorem je pro účely tohoto dokumentu myšlen jedinec nebo skupina osob.

1.2. Typografické konvence Názvy produktů jsou uvedeny kurzívou: Název produktu Ukázky programového kódu jsou uvedeny také kurzívou: Nějaký kód

1.3. Cílová skupina Tento dokumentu byl vytvořen především pro manažery a řídící pracovníky firem, neziskových organizací nebo státních institucí.

1.4. Cíl dokumentu Účelem této metodiky je poskytnout návod administrátorům, jak postupovat při rozhodování o možném přechodu na technologie postavené na OSS. Zároveň popisuje v širších souvislostech, jak by takový přechod měl být realizován. Záměrem bylo připravit materiál praktický pro administrátory s důrazem na srozumitelnost. V žádném případě se nejedná o učebnici nebo referenční příručku k určitému výrobku. Důraz byl kladen na strukturu dokumentu, která se dá snadno přepracovat tak, aby budoucí aktualizace v důsledku změn a přirozenému vývoji v uvedených produktech byly snazší. Pokud má tento dokument plnit svůj cíl i v budoucnu je zcela nevyhnutelné jej udržovat v aktuálním stavu. Jakékoliv připomínky, návrhy a vlastní zkušenosti nám můžete posílat prostřednictvím emailové adresy [email protected].

5

Cílem tohoto materiálu není informovat čtenáře v obecné rovině o přínosech OSS, licenční politice atp. Tyto informace mohou být nalezeny na stránkách Poradenského centra pro podporu implementace opensource software (www.vasemoznosti.cz) a po dohodě konzultovány v rámci poradenské činnosti Institutu pro informační společnost.

6

2. Stručný přehled Tato metodika je určena IT manažerům, managementu, ale i řadovým uživatelům, kteří uvažují o přechodu na Open Source software (OSS). Materiál obsahuje návod postavený na znalostech a zkušenostech tvůrců a jsou v něm zohledněny připomínky a výsledky testování různých subjektů, které mají konkrétní zkušenost s přechodem na otevřenou platformu. Postupy byly ověřeny v rámci fungování Poradenského centra pro podporu implementace opensource software, které provozuje Institut pro informační společnost. Existuje mnoho důvodů, proč přejít na OSS řešení. Mezi hlavními jsou například otevřenost vůči dalším úpravám software v případě růstu nároků organizace, vysoká úroveň bezpečnosti a zabezpečení, eliminace nucených změn z důvodu politiky komerčního dodavatele řešení, pořizovací náklady na software. Všechny tyto výhody je možné vyčíslit do podoby úspor, kterou implementace a provoz open source technologií představuje. Tento dokument doporučuje: ●

před začátkem přechodu mít zcela jasno v důvodech, proč migrovat na nové řešení

●

mít zajištěnou aktivní podporu ze strany správy IT, případně uživatelů

●

pracovník odpovědný za změnu by měl být s přechodem plně ztotožněn

●

mít vypracovanou expertízu a tým pro přechod na OSS

●

začít přechod na systémech, které nekontrolují kritické funkce organizace

●

ujistit se, že každý krok při přechodu je možné řídit a hodnotit

Jakákoliv změna v ITC systémech představuje příležitost upravit vnitroorganizační procesy a pracovní toky. Je nutné mít pře započetím migrace mít ujasněno: ●

jak bude zajištěna vzájemná součinnost jednotlivých částí systému

●

jak bude zajištěna podpora pro mobilní uživatele

●

jak bude zajištěna podpora a bezpečnost pro vzdálené uživatele

●

jak vybudovat sytém, který je udržitelný a řízený (v souladu s např. ISO atp.)

Zvláštní pozornost je třeba věnovat

nastavení bezpečnostních pravidel již na začátku

procesu plánování migrace. Nasazení OSS v oblasti serverů je obecně velmi rozvinuté i zdokumentované. Migrace serverů na OSS může být obecně provedena bez jakýkoliv dalších dopadů na uživatele a obyčejně je to prvním krokem, ke kterému se organizace uchylují.

7

Umístění OSS na pracovní stanice představuje pro většinu organizací výrazné úspory. V případě přechodu na OSS na pracovní stanicíce je potřeba věnovat pozornost funkčnosti propojení se stávajícími aplikacemi a tzv. groupware. V situacích, kdy dochází k nahrazování proprietárního software, který má na starosti automatizaci v rámci kancelářských operací, je nutné zajistit, aby šablony a funkce produkovaly požadované úkony a výstupy. Problematika maker v takových případech musí být obyčejně řešena skripty. Aplikace, které nemají OSS alternativu, mohou být spouštěny prostřednictvím tenkých klientů. S postupem času je nabídka OSS aplikací pro pracovní stanice stále širší a kvalitnější.. Tento dokument souží jako metodika pro kompletní přechod na OSS, avšak v situacích, kdy jsou užívány tisíce pracovních stanic, je nutné počítat s delší prodlevou v realizaci. Kombinace nasazení OSS a komerčních aplikací bývá v takových případech nezbytná. Některé procesy je možné svědomitě svěřit OSS aplikacím. Rozhodnutí by měla být dělána s vědomím nadčasovosti, aby v budoucnu nemohlo dojít k závislosti na konkrétní technologii nebo proprietárním formátu. OSS technologie jsou revoluční, protože z marketingového hlediska mění

produktově

orientované organizace na sektor služeb. OSS software je možné instalovat bez nákladů na pořízení. Důležité je však vzít v potaz otázku podpory.

Přestože dnes existuje řada

organizací, které se věnují poskytování podpory, je důležité znát odpověď na otázku podpory. Spoléhat se v této záležitosti na komunitu by bylo velmi nezodpovědné a pro fungování organizace svazující. Naopak sdílení know how a technologií v rámci skupiny organizací může výrazně snížit náklady na implementaci a správu IT.

8

3. Metodika Testování nebo zkoušení přechodu by mělo obsahovat následující:  Fáze sběru dat a definice projektu •

Popis výchozí situace

•

Architektura systémů

•

Aplikace a asociované datové zdroje



Použité protokoly a standardy



Hardware



Fyzické prostředí (rozmístění sítí, propustnost)



Lidské zdroje (požadavky na znalosti)

Popis záměru

o •





Architektura systémů



Aplikace a asociované datové zdroje



Použité protokoly a standardy



Hardware



Fyzické prostředí (rozmístění sítí, propustnost)

Lidské zdroje (požadavky na znalosti)

Popis plánu, jak se dostat od výchozího stavu k záměru

 Zhodnocení nákladů a klíčových faktorů nutných k úspěšné migraci na OSS  Návrh testovací fáze, která má ověřit funkčnost záměru, testování  Úprava realizačního plánu podle výsledků testování  Realizace  Monitoring odchylek oproti plánu a zapracování provozních zkušeností Obsah prvního bodu výše uvedeného postupu je popsán dále v tomto materiálu v kapitole „Scénář“ popsán detailněji s návodem jak přejít na OSS za určitých okolností. Tento návod pochopitelně nemůže být vyčerpávající, protože nemohou být pokryty veškeré možné modelové situace, které mohou v praxi nastat. Vybrána byla různá cílová prostředí (1.2) a zjednodušeny byly příklady výchozího stavu (1.1). Cílové prostředí je diskutováno v třetím oddíle tohoto dokumentu. Definované cílové prostředí umožnilo připravit scénář přechodu od zjednodušeného výchozího stavu.

9

V případě potřeby může být metodika v budoucnu doplněna o nové kapitoly, které by popisovaly jiné modelové situace podle aktuálních dispozic. Nové kapitoly tak mohou být napsány na základě konkrétních úspěšných případů migrace. Rozhodování o přechodu na OSS se neobejde bez systematického posouzení (2. bod) nákladů a přínosů. Z tohoto důvodu tato metodika obsahuje také tabulku nákladů, která ukazuje, jak jednotlivé scénáře mohou být nákladné a co obnáší přechod na OSS. Protože jsou úspěšné případové studie o nasazení OSS málo publikované, je součástí přílohy několik studií o nasazení OSS. Tato metodika se tak stala sborníkem úspěšných příkladů a zkušeností celé řady subjektů, které se přechodem na OSS intenzivně zabývají. Velké množství vstupních situací a cílových

záměrů představuje obrovské množství

kombinací řešení, které mohou být na organizaci aplikovány. Metodika je kvůli přínosu pro praxi napsána v duchu toho co se dělalo a jak, než aby popisovala, co by mohlo být uděláno. Prostor, který vzniká pro případné dotazy, by měl být vyplněn například poradenstvím buď IPIS nebo libovolného subjektu, který se otázkou migrace seriózně zabývá. Ve specifických případech pochopitelně může být žádoucí zachování určitých proprietárních systémů, to však záleží již na rozhodnutí realizátora.

10

4. Manažerská příručka 4.1. Přehled migrace Většina činností a úkonů, které musí být v rámci přechodu na OSS provedeny, jsou v podstatě totožné s těmi, které se týkají přechodu na jakýkoliv jiný proprietární software. I v případě nákupu tzv. krabicového software je třeba zajistit propojení a provést určité úkony, které zajistí správné zavedení nového software nejen po stránce technické, ale především organizační, aby investované prostředky byly efektivně využívány a přirozeně vedly ke zlepšení chodu organizace. Jakékoliv změny tak musí být nadčasově promyšleny a naplánovány bez ohledu na licenční politiku, kterou se dané řešení řídí. Tato příručka není návodem ani vyčerpávajícím seznamem úkonů pro projektového manažera. Vycházíme z předpokladu, že odpovědný administrátor disponuje potřebnými zkušenostmi vést projektově řízený přechod na jiná technologická řešení. Níže uvedené body jsou sumářem kroků, které musí být vzaty v potaz, aby přechod proběhl hladce. Některé aktivity mohou samozřejmě probíhat paralelně, avšak to již záleží na konkrétní volbě přístupu, který pro migraci zvolí projektový manažer. Také je nutné vzít v potaz, že skutečný realizační plán se sestavuje samozřejmě na základě konkrétního výchozího a cílového stavu a dispozic, které organizace zrovna

má. řada

administrátorů se tak může rozhodnout, že problematiku OSS budou pouze sledovat jako příležitost, kterou mohou za určitých okolností využít (např. jakmile organizace expanduje atp.) Více o nadčasovém přístupu administrátorů je napsáno níže v kapitole „Nadčasový přístup“. 4.1.1. Vytvoření týmu s odpovídajícími znalostmi a manažerskou podporou. Manažerská podpora je v tomto bodě klíčová, protože všechny organizace mají sklony k rezistenci ke změnám bez ohledu na řešení. Tato podpora musí být dostatečně silná, aby bylo možno realizovat pilotní odzkoušení na reprezentativním vzorku systémových operací. Následně se dá vytvořit kompletní plán, který bude zohledňovat netechnické atributy, které změna v organizaci vyvolá. Počet pozitivních by měl pochopitelně převažovat nad negativními. 4.1.2. Pochopení cílového prostředí bez ohledu na platformu a znalost možností, které existují a jsou k dispozici. Tento bod může zahrnovat nejen odborné konzultace, ale také nábor nových lidí nebo zvyšování kvalifikace a znalostí stávajících pracovníků. Tento bod již

11

obnáší citelnější investici, proto je nutný souhlas vedení organizace. Názor, že software, který je zdarma, může být implementován bez nákladů, je naprosto zcestný a nebezpečný! 4.1.3. Příprava na migraci je příležitostí k revizi stávající architektury a systému pracovních toků. Návrhem možné architektury s ohledem na efektivní řízení je možné se dočíst dále v tomto dokumentu, kde jsou popsány i výhody, které určitý přístup má, a také náklady/problémy, které nese. 4.1.4. Pochopení OSS: •

Problematika licencí by měla být zvládnuta (některé organizace mají ze zákona povinnost evidovat software). Pro účely účetnictví, evidence, ale i nastavení odpovědnosti v organizaci je vhodné mít zavedený Software Management, který eliminuje např. používání nelegálního software z nevědomosti nebo nedbalosti a chrání organizaci před konsekvencemi porušení autorských práv.

•

Znalost produktových možností. V rámci distribuce OSS mohou může existovat i několik programů, které plní určitou funkci. Migrační tým by měl znát pro a proti jednotlivých produktů tak, aby byl schopen vybrat nejvhodnější softwarový nástroj.

•

OSS je šířen v různých distribucích, ve kterých může být podstatný rozdíl. Některé z distribucí mají poradenské zázemí, které poskytují komerční firmy. Také přístup k aktualizacím a úpravám software je různý. Některé distribuce zahrnují pouze řádně otestovaný, ale starší software, jiné obsahují novinky, které však mohou mít chyby, které jsou odstraňovány až s postupem času.

•

Administrátoři musí mít ujasněno, jakou úroveň podpory očekávají. Komerční podporu mohou získat buď od vývojáře aplikace nebo od třetí strany, která se poskytováním podpory živí. Toto je zásadní rozdíl od komerčního software, u kterého se uživatel vázán na podporu pouze u autorizovaných firem, které mají přístup ke zdrojovému kódu. Problémem se tak může stát, pokud proprietární software zastará a výrobce jej už dále nevyvíjí nebo neposkytuje k němu podporu. Administrátoři mohou řešit problémy i v rámci vývojové komunity, avšak tento způsob není zcela nejefektivnější, avšak v případě kvalitního personálního obsazení IT může mít své příznivce.

4.1.5. Audit stávajícího systému. Tato data jsou užitečná nejen pro účely migrace, ale především odhalí skutečné náklady na provoz stávajícího ICT řešení. Data jsou výchozím

12

podkladem pro plán migrace,

protože vytváří vztažnou soustavu, vůči které se mohou

porovnávat náklady a přínosy s pojené s realizací cílového záměru. Audit by měl zahrnovat: Softwarový audit •

Název aplikace, číslo verze, zodpovědná osoba

•

Počet instalací / počet licencí / počet uživatelů

•

Operační systém / jiné OS, na kterých může být aplikace provozována

•

Jiné aplikace, které jsou nutné k zajištění chodu této aplikace

•

Hardwarové požadavky / použitý hardware

•

Jaké protokoly jsou použity pro komunikaci s dalšími aplikacemi

•

Jaké formáty souborů jsou podporovány / požadovány

•

Jaké jsou používané jazyky, měny, znakové sady a jiná specifická nastavení

Datový audit – jaká data jsou požadována, kým jsou užívána, jak je s nim i nakládáno •

Determinace problémů, které jsou mimo kontrolu administrátora, avšak jsou vytvářeny interními procesy za použití ICT

•

Popis požadavků na uchování dat (zálohy a archivace) o

Data, která nemusí být uchovávána a jsou zbytečná

o

Data, která musí být uchována a již jsou v otevřeném formátu nebo mohou být do něj snadno převedena. Zohledněn musí být čas/náklady převodu.

o

Data, která musí být uchována, ale jsou v proprietárním formátu, který nemůže být snadno převeden do otevřeného formátu. Tato data mohou požadovat, aby byly zachovány některé proprietární aplikace. V závislosti na požadavek přístupnosti těchto dat by měl být stanoven minimální počet kopií aplikací k otevření, který musí být zachován do budoucna. Popsány musí být také specifické hardware požadavky, je-li to nutné.

Bezpečnostní požadavky •

Jaký je používán stávající systém pro přiřazování loginu a hesla jaká je politika pro aktualizaci hesla

•

Jsou používány jiné systémy autentifikace než pouze uživatelské jméno a heslo

•

Je regulacemi (zákonem nebo interně) omezeno používání konkrétních

13

nástrojů (např. internet, e-mail) atp. •

Jaké bezpečnostní zařízení je používáno, které vyžaduje speciální hardware

4.1.6. Vytvoření detailního plánu pro přechod, který je postaven na informacích získaných viz výše. Plán musí obsahovat: •

Náklady výchozího (stávajícího) prostředí v horizontu cca 5 let s relevantními odhady

•

Náklady alternativních prostředí včetně ceny za migraci za stejné časové období

•

SWOT analýza stávajícího a cílového prostředí, doplnění o alternativy

4.1.7. Konzultace s experty. Je nutné zjistit veškeré dopady a důsledky migrace. Dřívější zapojení expertů znamená dřívější odhalení problémů, které stojí úsilí a tedy peníze. Experti by měli testovat i pilotní model. Experti zároveň vnesou vnější pohled na organizaci, což ji posune vpřed po stránce efektivity. Je důležité vytvořit „help desk“, aby mohly být rozptýleny obavy a fámy, které se mohou během migrace vyskytovat. Intranet je vhodným nástrojem, který poskytne uživatelům nejen informace, ale i prostor pro vzdělávání. Tato sekce zapadá do knowledge managementu firmy. 4.1.8. Zahájení pilotních projektů začíná ihned po dokončení plánu migrace. Pilotní projekty by měly běžet v reálném prostředí, ale s omezenou skupinou uživatel. Testování v rámci pilotáže by mělo poskytnout: •

Data pro upřesnění nákladovosti jednotlivých řešení

•

Reakce uživatelů na nová řešení

•

Evaluace a úprava cílové architektury a migračního plánu

4.1.9. Určení metody a rychlosti přechodu na nové řešení Je velmi pravděpodobné, že nový a starý systém budou muset po nějakou dobu fungovat současně. Protože výměna posledního PC může být až za dlouhou dobu, nebo se nikdy nestane, je mimořádně důležité zajistit ko-existenci obou systémů tak, aby nebyl narušen chod organizace. Výměna může probíhat následujícími způsoby: •

Big Bang – rychlý přechod, kdy všichni uživatelé mění starý systém za nový ve stejném čase. Prakticky to znamená připravit nové řešení během víkendu nebo v době svátku. Výhoda tohoto přístupu tkví v tom, že administrátor nemusí udržovat duální systém a uživatelé nemusí přepínat mezi novým a

14

starým systémem. Nevýhodou je velmi vysoké riziko a požadavky na zdroje v době změny. Tento přístup je použitelný pouze u malých organizací. Tento přístup velmi pravděpodobně bude představovat spoustu problémů, které budou muset být za chodu řešeny. Vzniklé chyby pak nejsou chybou například OSS řešení, ale chybou projektového manažera. •

Fázový přesun ve skupinách – uživatelé přecházejí na nový systém ze starého ve skupinách. Je velmi pravděpodobné, že při přechodu funkční skupiny najednou se minimalizují problémy spojené s sdílením dat a jiné spolupráce ve skupině. Míra rizika a management zdrojů může být ovlivněn volbou správné velikosti skupiny. Je možné provést např. záměnu hardware (pracovních stanic) za nově připravené. Stávající stanice pak budou přeinstalovány, a pak předány další skupině uživatel.

•

Individuální přechod – uživatelé přecházejí na nové řešení jednotlivě. Tento přístup je velice zdlouhavý a nevhodný pro větší organizace, avšak je ideálním přístupem pro pilotní fázi.

4.1.10.Zapojení všech administrátorů. Je samozřejmé, že migrace bude představovat zaškolení personálu i techniků (školitelů). 4.1.11. Sledování zpětné vazby ze strany uživ\tel a opravy problémů, které se objevily. Některé požadavky uživatelů mohou být natolik zvláštní, že nemohly být předvídány nebo identifikovány v průběhu pilotního odzkoušení. Je nutné s tímto bodem počítat a vyčlenit pro realizaci dostatek zdrojů. V kterékoliv části realizace může nastat situace, že migrace není proveditelná. Tyto situace mohou nastat, pokud nebylo provedeno otestování a kompletní nahrazení kritických aplikací nebo alternativní řešení by bylo příliš nákladné.

4.2. Lidské zdroje Tato příručka není také příručkou řízení lidských zdrojů, přestože administrátoři a projekt manažer se bude muset s pravidly řízení lidských zdrojů potýkat. Personalisté by měli být zapojeni do projektu již ve fázi příprav, protože je nutné, aby motivovali pracovníky ke změně. Důraz by měl být kladen na přínosy, které zaznamenaly jiné organizace, co přešly na OSS řešení. Stěžejní je dobrá informovanost pracovníků o aktuálních postupech a konzultace jejich

15

potřeb. Jednou z možností, jak efektivně komunikovat změnu a získávat zpětnou vazbu je sdílený intranet, který je možné snadno aktualizovat. Přístup ke školení je velmi důležitý. Zatímco některé organizace ponechávají rozhodnutí o nutnosti zaškolení na pracovnících, jiné účast na školení vyžadují. Je nutné si uvědomit, že při přechodu na jakékoliv nové řešení nejde o jen o znalost nové technologie nebo její intuitivní znalost, ale především o nová pravidla administrace, sdílení dat nebo jiné spolupráce. V případě nových technologií je třeba počítat s faktem, že dokumentace k většině opensourcových technologií je v angličtině, což může znamenat překážku u některých uživatelů. Náklady na překlady a lokalizaci software spolu s tvorbou

nebo překladem nutných

dokumentací a příruček k proškolení pracovníků jsou součástí nákladů na migraci na open source řešení. Vyřešit je nutné také problém s aktualizací, aby se software

nebo

dokumentace nemusel po každé aktualizaci znova upravovat, což by zvyšovalo náklady na správu systému a snižovalo výhodu, kterou by měl open source software přestavovat. Moderní uživatelská prostředí Gnome a KDE poskytují výběr řady jazyků a významnější aplikace jsou obyčejně lokalizovány, avšak nápověda bývá obvykle pouze v angličtině. Přechod na nové řešení představuje klasické reakce lidí na změnu v pracovních procesech, se kterými je třeba počítat: Strach z neznámého Nová OSS platforma bude pro většinu lidí zcela novou zkušeností, proto se budou proti této změně bránit, jelikož strach z neznámého je přirozený a OSS je pro ně něco nového. Na druhé straně existuje skupina osob, pro kterou bude změna novou výzvou zkusit si něco nového a právě této skupině by mělo být OSS řešení představeno jako prvním. Schopní lidé s nadšením poskytnou nejen zpětnou vazbu v době příprav, ale také budou vytvářet pozitivní prostředí pro změnu působením na ostatní. První skupina uživatelů je zaškolena v průběhu pilotního testování. Jakmile si osvojí nové procesy mohou být nápomocni při motivaci a zaškolení svých kolegů. V každém případě je nutné mít připravené školící materiály a stálý přístup k intranetu pro pomaleji se učící personál. Tentýž proces je možná aplikovat na systémové pracovníky s rozdílem, že rozsah znalostí musí být mnohem širší. Strach z neznámého u systémových pracovníků by měl být překonán již v úvodní fázi příprav. Systémoví pracovníci budou plnit funkci podpory, u které budou jiní uživatelé později hledat odpovědi na své dotazy. Pokud by systémoví pracovníci nebyli zcela ztotožnění s funkčností navrženého řešení, pak by nemohli přesvědčivě radit s přechodem a chodem OSS.

16

Kariérové obavy U řady ambiciózních zaměstnanců může nastat situace, kdy se budou obávat, že „nestandardní“ řešení, kterým z hlediska zažitého fungování ICT světa OSS bezesporu je, jim bude činit problémy v dalším kariérovém postupu. Tento skrytý problém není radno podceňovat, protože dokud nebude OSS všeobecně akceptován jako standard či výhoda, lidé mohou být vůči učení se něčemu novému rezervovaní. V dnešní době je možné pozorovat nepsaný trend, že open-sourcoví specialisté jsou hodnoceni lépe než jejich kolegové pracující s komerčními produkty. Sebevědomí Lidé, kteří znají současný systém a procesy velmi dobře, mohou ztratit o OSS řešení zájem v případě, že zjistí, že nové řešení je od stávajícího odlišné. Tito lidé jsou přirozenou podporou v organizaci, protože mohou pomáhat řadovým pracovníkům s problémy, do kterých se během plnění pracovních povinností mohou dostat. Tito lidé by však neměli být začleněni do týmu pro pilotní odzkoušení ani mezi

první proškolené pracovníky, protože jejich

přesvědčení musí být náležitě opečováváno.

4.3. Užitečné postřehy Během přechodu na OSS se objeví řada okolností, které je dobré mít na paměti: Představení nových aplikací ve známém prostředí Spousta OSS aplikací bude funkční i v proprietárním operačním systému, což vytváří pracovníkům možnost plynule se seznámit s novými aplikace ve známém stávajícím prostředí.

Jako příklad takových aplikací je možné jmenovat prohlížeč Firefox, software

Apache, OpenOffice nebo Thunderbird. Tento přístup může pro uživatele znamenat méně drastický proces bez nutnosti složitého přeškolování a další změny mohou být také snadněji komunikovány v návaznosti na dobrou zkušenost, kterou budou uživatelé s novými aplikacemi mít. Také nesnáze, které mohou vyvstat v souvislosti s novými formáty a potřebou konverze budou daleko lépe řešeny, pokud po přechodnou dobu paralelně poběží stávající aplikace. Problémy s makry a šablonami je také možno řešit v daleko méně hektickém období,

kdy

změny

v

souvislosti

s

přechodem

nebudou

ještě

tak

znatelné.

Tento přístup znamená, že výběr nových aplikací by měl být podmíněn existencí verze pro stávající operační systém. Přestože existuje např. e-mailový klient s pokročilými funkcemi (Evolution), pro účely přechodu může být vhodnější volbou Thunderbird, který existuje i na komerční platformě.

17

Začít změnu se snadnými programy Změny, které jsou dělány na první úrovni, nebudou vyrušovat uživatele. To znamená, že změny na straně serveru nemusí být vůbec pozorovány a přitom vytvoří dobrou komunikační platformu pro představení plánovaných změn na straně pracovních stanic. Řada OSS změn na straně serveru, kterých si uživatel vůbec nevšimne, je zcela kompatibilní s komerčním řešením. Typickými příklady, kdy stávající řešení může být nahrazeno OSS ekvivalentem bez ohrožení kompatibility, jsou DNS servery, DHCP servery, databázové servery atp. Detailněji jsou tato nahrazení popsána dále v tomto dokumentu. Některé aplikace jako např. Samba, které nemohou být požity v OSS prostředí umožňují souběžné fungování proprietární i OSS platformy. Časné nasazení těchto aplikací může být prospěšné, protože zefektivní rozdělení přechodu do snadněji zvládnutelných etap. Nadčasový přístup V případě, že změny spojené s přechodem budou dělány minimalisticky bez ohledu na budoucí vývoj, mohou nastat komplikace při pokročilejších fázích přechodu. Je nutné mít na paměti: •

Nově připravované webové aplikace se musí správně zobrazovat jak ve starých, tak i nových OSS prohlížečích. K dispozici je spousta nástrojů pro verifikaci webových aplikací, které testují správné zobrazování aplikace. Odpadá tak problém nutnosti používat specifické prohlížeče obsahu. Tento požadavek by měl být dodržován bez ohledu na to, zda jsou aplikace vyvíjeny pracovníky příslušné organizace nebo externím dodavatelem.

•

Makra a skripty v dokumentech by měly být nahrazeny jinými technikami, které by zajistily podobnou funkcionalitu. Tato změna je zároveň změnou k dobré praxi, že eliminací maker se výrazně snižuje riziko infikování souborů jednoduchým virem, který může mít za následek ztrátu, zneužití nebo jiné poškození dat a systému.

•

Používání rozšířených OSS formátů, které se staly standardy (např. pdf). Je zcela zbytečné používat pro dokumenty, které nejsou určeny pro další editaci, proprietární textové formáty, které jsou navíc náchylnější pro šíření virů, obsahují také metadata o chování uživatele, která mohou být snadno čtena jinými. Ani vymazaný text tak není skutečně smazaným, což může vést k úniku některých informací o historii dokumentu atp. Zároveň používáním proprietárního software pro tuto formu dat se zbytečně buduje budoucí závislost na konkrétním nositeli práv k danému formátu. 18

•

V případě psaní dokumentu ve spolupráci s dalšími osobami je vhodné používat ten nejnižší obecný formát, ve kterém se dá pracovat, protože se tak sníží závislost na pořízení nového software v rámci pracovní skupiny. Navíc se zjednoduší přechod na OSS řešení díky lepší kompatibilitě se staršími verzemi.

•

Je vhodné používat tzv. open standard protocols, za které jsou považovány protokoly bez patentové ochrany, a které jsou šířeny s OSS. Existují různé sady těchto protokolů, které jsou rozšířeny v závislosti na geografickém území a mohou obsahovat drobné odlišnosti (např. OSOSS nebo SAGA).

•

Nově vyvíjené systémy by měly být na tzv. 3-tier architektuře – detailněji viz další kapitola. Aplikační kód by měl být nezávislý na lidských zásazích a metodách přístupu k datům. Aplikace by měly být budovány modulárně, aby např. webové rozhraní podporovalo OSS webové prohlížeče atp., což umožní přechod ve fázích a také sníží riziko kolapsu v době přechodu. Tradiční „monolitické“ aplikace jsou z hlediska budoucího vývoje nepraktické.

•

Všechny nové aplikace by měly být přenositelné (multiplatformní), což představuje využívání standardizovaných jazyků jako Java, Python nebo Perl, a také multiplatformních knihoven a GUI nástrojů jako wxWindows nebo FOXtoolkit.

Nové

aplikace

by

neměly

vyžadovat

přítomnost

dalších

proprietárních aplikací nebo specifických jazyků a APIs. •

Proprietární čtečky pošty, které užívají proprietární formáty na úschovu pošty nebo komunikují se servery prostřednictvím proprietárních protokolů, by měly být nahrazeny dostupnými alternativami pro uchovávání adresáře nebo kalendáře.

19

5. Technická příručka 5.1. Referenční architektura 5.1.1. Generická architektura Jednou z cest jak popsat schéma architektury je tzv. 3-tier model. Tento model se sestává ze tří hlavních funkcí, které plní aplikace, když jsou používány člověkem. Nejedná se tedy o funkce vyvolané čistě serverovou či batch aplikací. Obr. č. 1 ukazuje jak jsou předávány informace mezi třemi částmi modelu. Toky informací by v ideálním případě používaly otevřené standardy. Jednotlivé části fungují nezávisle, což znamená, že aplikace se stará pouze o svou vlastní logiku, zatímco další funkce jsou ponechány standardním komponentům. Díky tomuto přístupu může být aplikační kód jednodušší a také může mnohem snadněji fungovat v jiném prostředí.

Přístup k datům

Kód aplikace

Lidské rozhraní

Souborové systémy

Logická struktura

Periférie

Obr. č. 1 Tento 3-tier model může být dále rozvíjen jako n-tier, protože komponenty mohou být dále členěny, a tak je realizován za pomocí objektové nebo komponentní technologie. Spousta klient-server aplikací v minulosti používala 2-tier model, kdy aplikační kód a lidské rozhraní byly spojeny v jedno. V případě migrace to přináší více problémů něž u modelu 3tier. Důvodem jsou požadavky na určitá uživatelská rozhraní, která vyžadují změny, avšak 2-tier aplikace mají lidská rozhraní zakomponována do logické struktury aplikace. Komunikace mezi třemi částmi 3-tier modelu se obvykle realizuje prostřednictvím protokolů, což umožňuje, aby jednotlivé části byly provozovány na zcela odlišných počítačích. Protože některé části mohou být rozděleny, vniká prostor pro skutečně variabilní architekturu, podle požadavků organizace. Z pohledu pracovní

stanice, na které musí obvykle běžet alespoň minimální kód

20

zprostředkovávající uživatelské rozhraní, existují dvě extrémní řešení. Velmi tenký klient Pracovní stanice v tomto případě obsahuje pouze kód pro uživatelské rozhraní. Obyčejně tato zařízení neobsahují ani prostředky pro dlouhodobé uchování dat (např. hard disk). Aplikační kód a přístup k datům běží na jiných počítačích. Příkladem může být např. X terminal, VT100 (zelená obrazovka) nebo zařízení se zabudovaným prohlížečem. Velmi tlustý klient V tomto případě jsou veškerá data i kód provozována na pracovní stanici, která není zapojená do sítě. Termíny tenký nebo tlustý klient pak leží někde ve spektru možností mezi výše definovanými extrémy. Variací možnosti těchto architektur je případ, kdy je aplikační kód uložen na serveru a pracovní stanici a je načten v případě potřeby. Tento postup je znám např. z Java appletů. Jinou metodou, která představuje uložení aplikačního kódu na serveru, ke kterému je přistupováno z pracovní stanice, jako by byl kód uložen lokálně. To požaduje využití síťového souborového systému (např. NFS), což také znamená, že všechny pracovní stanice musí mít stejnou architekturu procesoru (CPU). Výběr architektury pro konkrétní aplikaci bude záležet na několika faktorech: •

Průchodnost sítě k serverům a maximální průchodnost, kterou síť unese. V případě, že klientem není velmi tlustý klient, pak prostřednictvím sítě budou přenášena kontrolní rozhraní, data i aplikační kód. V některých případech může velikost těchto dávek generovaných buď jednou pracovní stanicí nebo několika ve skupině být příliš velká, než co umožňuje kapacita průchodnosti sítě.

•

Latence (odezva), která je přijatelná pro použití aplikace. Kdykoliv lidé pracují s pracovní stanicí (stlačí nějakou klávesu nebo pohnou myší) vzniká latence mezi úkonem člověka a reakcí počítače, která tuto činnost vykreslí na obrazovku. U některých aplikací se vyšší míra latence snese (jednoduché vkládání dat), avšak u náročnějších operací, jako je např. kreslení musí být odezva rychlá. Míra latence závisí na kapacitě sítě mezi lidským rozhraním a aplikacemi, a také na výkonnosti počítače, na kterém běží kód aplikace. Pro dosažení nejnižších latencí je ideální provoz aplikace na stejném počítači jako běží lidská rozhraní a počítač je dostatečně výkonný.

•

Nastavená bezpečnostní politika. Pokud jsou data uložena na pracovních 21

stanicích, pak v případě zcizení nebo přístupu neoprávněnou osobou v situacích, kdy data nejsou dostatečně zajištěna, může dojít ke zneužití důvěrných informací. Tento problém nenastává v případě, že na pracovních stanicích jsou uchovávána pouze data s nízkou úrovní stupně utajení a data jsou pečlivě zálohována. Administrátor samozřejmě nastavuje přístupová práva k datům. Jiným problémem je přenos nezašifrovaných dat sítí. •

Politika zálohování dat. Centralizovaný zálohovací mechanizmus je nutný i v případech pokud jsou data uchovávána na pracovních stanicích. Jinou možností je zavedení individuálního systému záloh mezi jednotlivé uživatele pracovních

stanic.

Schéma

centralizovaného

zálohování

vyžaduje

dostatečnou průchodnost sítě a spolupráci s uživateli, kteří např. nesmí vypínat pracovní stanice v době plánovaných záloh dat. •

Návrh aplikace. Pokud aplikace zahrnuje kód lidského rozhraní, pak aplikace musí být provozována na pracovní stanici nebo na serveru a kód lidského rozhraní musí být spouštěn jak na serveru, tak na pracovní stanici. Pro ilustraci IBM nebo DEC terminály mají uložen kód pro display uložen na pracovní stanici (prohlížečové terminály). Citrix Windows Terminal Sever nebo X Window System mají zobrazovací kód pro display rozdělen mezi server a pracovní stanici.

•

Výkonnostní kapacita pracovních stanic ke zpracování kódu. Pravidlem je, že čím více procesů pracovní stanice dělá, tím výkonnější musí být. Požadavek na výkonnost pracovních stanic se pochopitelně projevuje v pořizovací ceně takových zařízení.

•

Kapacita desktopu skladovat data. Některé aplikace mohou vyžadovat obrovské množství dat,

které mohou být udržovány na specializovaných

serverech. •

Výkonnost disponibilních serverů.

Aplikace, které běží na straně serveru,

vyžadují dostatečný výkon serveru, aby bylo možné obsloužit všechny pracovní stanice. V praxi to znamená, že servery musí být dostatečně dimenzované , aby se zvládly vypořádat s nejnáročnější situací. Vzhledem k vysokým pořizovacím nákladům se výkonnější servery, které by poskytovaly rezervu nepořizují. Při zapojení dalších pracovních stanic do sítě je pak nutné pořídit i nový výkonnější server. •

Celkové náklady na implementaci. Jedno řešení není přenositelné a aplikovatelné pro všechny situace, které mohou v praxi nastat, proto i k otázce celkových nákladů je nutné přistupovat individuálně a zodpovědně.

22

5.1.2. Základní referenční architektura Základní referenční architektura (ZRA), která je použita pro tuto příručku je vybrána s ohledem na použitelnost ve většině situací. Pochopitelně tato architektura může být libovolně rozšiřována nebo zeštíhlena podle potřeby. Ve skutečnosti architektura používaná administrátory je kombinace různých architektur, které jsou potřebné pro specifické aplikace. ZRA může být popsána následovně: •

Veškeré aplikace, pokud je to možné, běží na pracovní stanici a data jsou zálohována tamtéž.

•

Na pracovních stanicích nejsou udržována trvalá data

•

Veškeré autentifikace a autorizace jsou kontrolovány centrálními servery

•

System management je centralizovaný

•

Cílem je, aby pracovní stanice fungovaly na sytému „plug and play“ a nevyžadovaly místní podporu.

Aplikace mohou běžet lokálně, aby byl minimalizován problém s odezvou. ZRA předpokládá, že je k dispozici dostatečná průchodnost sítě, aby data mohla být uchovávána centrálně. Nutné je třeba podotknout, že všechny pracovní stanice musí být zcela identické, což umožňuje komukoliv, aby se přihlásil na jakýkoliv počítač, ke kterému je oprávněn přistupovat. Tato architektura vyžaduje silný system management, aby všechny pracovní stanice pracovaly po stránce software jednotně. ZRA požaduje centrální management a nastavení, která zjednoduší systém administrace. Veškerá důležitá data na centrálních serverech musí být připravena pro snadné zálohy, čímž se eliminuje možnost výskytu fatálních selhání z důvodu výpadku na straně pracovní stanice. Pokud jsou data uchovávána lokálně na pracovní, tak dochází k fixaci uživatele s počítačem. To může způsobit problém pře změně lokality v rámci organizace, pokud se například změní organizační struktura. Centralizace dat do jisté míry eliminuje tento problém a vytváří jistý prostor pro flexibilitu využití pracovních stanic.

Zapojením plug-n-play zařízení se

minimalizují nároky na instalace a podporu těchto zařízení v novém systému. V současné době spousta administrativních architektur pro zřejmé přednosti využívá ZRA, jako logický krok. ZRA není příliš vhodné řešení pro laptopy nebo pracovní stanice, které nejsou permanentně připojeny k síti. Taková zařízení musí být nakonfigurována ve formě velmi tlustého klienta nebo musí mít nainstalován takový distribuční souborový systém, který podporuje tzv. off-line

23

operace. Za příklady takových OSS souborových systémů je možné jmenovat např. CODA, OpenAFS, InterMezzo.

5.2. Funkční skupiny Referenční model je založený na funkčních skupinách, které definují typické druhy nespecializovaných počítačových aktivit v administraci. Specializované aktivity jako projekt management nebo geografické informační systémy, které mají pouze minoritní využití v rámci nasazení software v rámci organizace nejsou brány do úvahy. Funkční skupiny jsou rozděleny do Primárních a podřazených skupin. Primární skupiny zastupují funkcionalitu, kterou je možné definovat standardními operacemi v rámci řízení organizace. Podřazené skupiny poskytují podpůrné služby primárním skupinám, a tak samozřejmě nemá smysl implementovat je samostatně.

5.2.1. Primární skupiny Kancelářské balíky Vytváření, úprava a tisk souborů, které obsahují standardizované formáty pro obchodní data jako např. obchodní korespondence,

sestavy, tabulky nebo prezentace. Je nutné mít

možnost nakládat s takovými proprietárními formáty, jako jsou .doc, .xls, .ppt. Stejný přístup se týká pochopitelně i otevřených formátů, které musí být také čitelné a zapisovatelné za použití české znakové sady a jiných místních nastavení. Pošta Vytváření, příjem,, zobrazování elektronické pošty včetně podpory pro zabezpečenou poštu (např. S/MIME). Kalendář a groupware Vytváření a řízení osobního a skupinového

kalendáře a adresáře. Kalendáře musí

umožňovat administrativu mítink např. evidenci rezervací zasedacích místností atp. Adresáře by měly být schopné integrace s dalšími funkčními skupinami. Přístup na web Jedná se o možnost přístupu k internetovým protokolům a zobrazování výsledků. Obvykle je to prováděno prohlížečem. K dispozici by měly být nástroje, které umožňují vytvářet obsah webu, který by byl podle potřeby přístupný buď jen z interního nebo i z externího prostředí.

24

Správa dokumentů Centralizovaná správa dokumentů by měla obsahovat efektivní nástroje pro vyhledávání a o případně obnovu ztracených dat. Databáze Manipulace s daty v určité struktuře jak v personální tak i centrální databázi.

5.2.2. Podvojné skupiny Tyto

skupiny

jsou

obecně

definovány

technickými

službami

a

obyčejně

nejsou

implementovány samostatně. Tyto skupiny obsahují např.: •

operační systémy

•

souborové servery

•

správu uživatelů, autentizaci a autorizaci

•

antivirový a antispamový software

•

zálohy a obnovy dat

•

správa tisku

Podrobněji je tento seznam rozepsán níže. Do úvahy je nutné vzít několik požadavků, které mohou být v každém nasazení jiné. Rozdíly mohou být způsobeny jak národní nebo jinou určující legislativou (interní směrnice zřizovatele organizace), tak místními nastaveními či přítomností specifických poskytovatelů podpory atp. Obecně je třeba vzít do úvahy, že by měly být čitelné veškeré formáty MS Office, ale také třeba WordPerfect nebo Lotus Notes formáty. Některé aplikace si vyměňují informace mezi širokou skupinou uživatel a administrátory, což klade nároky na zabezpečené připojení.

5.3. Resumé referenčního modelu Široká škála dostupného OSS znamená, že pro řadu procesů lze možné najít alternativní aplikace. Výběr aplikace, která by měla být používána, není vždy úplně jednoduchý a často je finální výběr určen čistě preferencemi osob, které jsou oprávněny rozhodovat.

25

Referenční model, který byl použit v tomto dokumentu, je uveden jako příklad funkčního modelu, který funguje. V žádném případě však není možné k němu přistupovat jako k jedinému funkčnímu řešení, které může být nasazeno v každém případě, co může v praxi nastat. V příručce jsou zohledněny okolnosti, které by měli vzít odpovědné osoby do úvahy, aby dosáhli ke správným závěrům. Lokální obtíže, které mohou nastat, pak musí být eliminovány administrátory. Existuje spousta tuzemských a zahraničních referenčních webových stránek, které obsahují seznamy OSS aplikací., které mohou nahradit proprietární aplikace. Institut pro informační společnost je uvádí například na stránce www.vasemoznosti.cz. Jednou z evidentních výhod OSS řešení je, že může být tzv. modulární, což znamená, že může být skládán dohromady a kombinován různými způsoby za použití různých programů a plikací, a tak systém může být uzpůsoben na míru konkrétních požadavků organizace. Tato modularita je umožněna existencí volně přístupných rozhraní, které mohou být upravovány a mohou být znova zpřístupněny dalším uživatelům. Bohužel široká nabídka OSS může občas působit potíže při rozhodování o volbě konkrétního řešení. I v České republice působí několik firem, které se konzultacemi a podporou při nasazení vhodných aplikací komerčně zabývají. stejně jako při nasazení proprietárních řešení. Je nutné si uvědomit, že zdaleka ne všechny funkční skupiny mají na výběr z referenčních příkladů, protože k dispozici nemusí být zcela relevantní případová studie, ze které by se dalo volně čerpat. Základní referenční příklady, které čerpají jak z veřejně dostupných případových studií nebo z vlastních zkušeností autorů této metodiky, jsou uvedeny na konci v přílohách.

5.3.1. Pracovní stanice Operačním systémem je GNU/Linux z rozšířené distribuce (Red Hat1) Uživatelské grafické rozhraní využívá Gnome, které je integrovanou součástí řady distribucí. Individuálně je možné zvážit použití KDE, které nabízí širokou škálu uživatelských nastavení nebo Ximian, což je derivát Gnome, který má společné prvky také s KDE.

1 Komerční distribuce s plnou podporou. Volnou alternativou jsou například distribuce Ubuntu nebo Open Suse, které jsou rovněž velmi rozšířené a je možno v případě potřeby zakoupit oficiální komerční podporu.

26

Souborový systém obsahující binární formáty (např. /usr) jsou přednastaveny jako „pouze pro čtení“, aby bylo zabráněno uživatelům měnit jejich obsah. Zbytek je přednastaven jako „nevykonávat“, aby z nich nemohl běžet kód. Uživatelská rozhraní by tak neměla umožňovat uživatelům spouštět programy, které nejsou předefinovány v rámci konkrétního rozhraní. To znamená, že z příkazové řádky nebo prostřednictvím nějaké změny v nastavení menu nesmí být možné spouštět programy,

které administrátor nepovolil k užívání. V případě

bezpečnostních požadavků je vhodné se vyvarovat možnosti připojení disketových jednotek nebo jiných zálohových médií, které mohou obsahovat jiné souborové systémy. Souborové systémy obsahující nestabilní uživatelská data jsou připojovány z centrálního NFS serveru. Autentizace uživatelů je vykonávána oproti centrální LDAP databázi. Centrální DNS servery vytvářejí IP adresu a name resolution, zatímco DHCP server poskytuje pracovním stanicím při bootování detaily o síťovém

nastavení. Hlavní funkce

pracovních stanic obsahují následující: Kancelářské aplikace OpenOffice je doporučen, protože v případě migrace ze systému Windows může být tento software provozován i ve Windows. Uživatelé tak mají možnost seznámit se s novým software již ve známém prostředí. Podpora formátů produktů Microsoft Office je také velmi kvalitní (viz vasemoznosti.cz) Pošta Thunderbird je doporučen, protože stejně jako OpenOffice jej lze snadno provozovat i na platformě Windows. Vizuálně je velmi podobný produktu MS Outlook, čímž je uživatelům usnadněn přechod. Thunderbird může být používán i jako groupware. Lze jej snadno doplnit o celou řadu rozšíření, které umožňují například sdílení kalendáře a plánovače včetně evidence registrace zasedacích místností atp. Kvalitní antispamový filtr z něj dělá velmi kvalitní komunikační nástroj. Další alternativou, které má dobrou podporu např. v oblasti synchronizace s mobilními zařízeními, je aplikace Evolution, která však není vytvořena pro platformu Windows. Kalendář a groupware Kalendář a správa kontaktů je zpravidla integrována prostřednictvím rozšíření do poštovních klientů.

Za příklad samostatného groupware je možné jmenovat Kgroupware, který je

připravován tak, aby fungoval s poštovním klientem Kmail.

27

Přístup k webu Mezi nejrozšířenější aplikaci, která dobře alternuje k proprietárním produktům je Mozilla Firefox, která je často používaným prohlížečem i na platformě Windows. Uživatelé se tak mají opět možnost seznámit a pohodlně pracovat s OSS aplikací ve známém prostředí. V otázkách bezpečnosti je velmi úspěšný webový prohlížeč Opera obsahující řadu uživatelsky přívětivých prvků. V případě, že je třeba prohlížet web na počítačích s velice malou operační pamětí, pak v prostředí Linuxu existuje několik velmi jednoduchých prohlížečů s nízkými nároky na operační paměť počítače (např. Epiphany) Správa dokumentů Kvalitní správa dokumentů umožní zefektivnit procesy. Přestože existuje řada OSS projektů tz. Document Management System (DMS), jejich implementace nemusí být úplně triviální a vyžaduje asistenci zkušeného integrátora, který správu dokumentů do organizace zavede. Databáze Osobní databáze jsou obvykle na základě MySQL nebo webovém groupware (např. phpGroupWare). Samozřejmě volba databáze vychází z konkrétních požadavků zejména na rychlost atp.

5.3.2. Servery Servery jsou prostředím, kde nachází OSS své široké uplatnění již po řadu let. Volba konkrétního řešení opět bude zrcadlit potřeby vysoké bezpečnosti. Zatímco standardní servery je možné vybavit např. specializovanou distribucí Red Hat, pro firewally je vhodné použít OpenBSD. Základní serverové aplikace mohou obsahovat následující skupiny software: Pošta Jako tzv. Mail Transport Agent (MTA) je možné zvolit program Exim. Tento program je velmi podobný produktu Sendmail, ale lze jej snadněji udržovat. Protože Exim rozumí předvolbám, které používá Sendmail, lze jej snadno nahradit. Dostupnou alternativou je také program Postfix. Mail Access Agent (MAA) slouží k uchováváni pošty. Dobrou volbou je např. produkt Cyrus, přestože působí trochu složitěji než např. Courier-IMAP. Kalendář a groupware Tato problematika byla již řešena v rámci pracovní stanice. U groupware se předpokládá

28

chod na centrálním serveru, ke kterému pracovní stanice přistupují. Možnými řešeními používající webová rozhraní je např. PhpGroupWare nebo Horde. Webové služby Nejrozšířenějším produktem,

který na poli webových služeb působí je Apache, který

disponuje řadou nástrojů a kvalitní podporou. Některé servery, které jsou využívány pro specifické úlohy mohou využívat např. Zope. Správa dokumentů Stejně jako u groupware byla tato problematika řešena již u popisu pracovních stanic. Databáze Pro velké serverové databáze, které slouží k přístupu z velkého množství stanic převážně v režimu pouze pro čtení, je nejvhodnější řešení MySQL. Pro jiné typy databází se pak nabízí PostgreSQL.

5.4. Aplikace pro primární skupinu 5.4.1. Kancelářské balíky Současným „standardem“ v oblasti kancelářských aplikací je produkt MS Office, který zahrnuje textový editor, tabulkový procesor, prezentační software, emailového klienta a jiné. Tento balík používá formáty souborů, které nejsou otevřené a často se verze od verze liší. Nový formát tak není možné 100% otevřít ve staré verzi aplikace, čímž se stává zastaralou a méněcennou či nepoužitelnou. OSS aplikace jsou nyní schopné číst i tyto proprietární formáty v velmi dobrou přesností jak dokládá Studie vizuální kompatibility, kterou provedl na přelomu roku 2007 a 2008 Institut pro informační společnost (vasemoznosti.cz). Nepsané pravidlo také tvrdí, že

starší verze

proprietárního formátu jsou otevírány OSS s velkou přesností. OSS je v této proceduře paradoxně daleko úspěšnější než výrobce, který své staré verze nepodporuje. Přechod na OSS je v tomto ohledu bezproblémovou záležitostí. Složitější situace nastává pokud je soubor otevřen, editován a následně přeuložen. Pak mohou nastat odlišnosti, které mohou být způsobeny několika faktory. Těmito odlišnostmi se zabývá již uvedená Studie vizuální kompatibility. Pro účely této metodiky je však nutno zdůraznit, že tyto odlišnosti mohou nastat i mezi různými verzemi proprietárního produktu, a tak se nejedná o nedostatek, který by byl způsobován čistě OSS!

29

Nicméně výše uvedený nedostatek může být problémem v situaci, kdy je nutné zajistit spolupráci v rámci určité pracovní skupiny (tvořené např. externími subjekty) a jeden ze subjektů trvá na použití určitého proprietárního formátu. Tato situace v běžném prostředí znamená to, že celá skupina je nucena zakoupit novou verzi určitého software. Tyto situace je nutné řešit individuálně, protože bez ohledu na OSS řešení ve všech případech není nevyhnutelně nutné instalovat tentýž produkt na všechny počítače. Jak bylo již uvedeno výše, v situacích kdy není nutné soubor ve skupině upravovat, pak např. PDF formát je ideální řešení. Některé OSS aplikace se snaží vizuálním zpracováním přiblížit svým proprietárním protějškům. Přestože tato snaha může být výhodou, která snižuje náklady na přeškolení v případě migrace na OSS, je zvláštní, že nové verze proprietárních produktů bývají mnohdy daleko odlišnější než OSS a uživatelům přechod na novou verzi problémy nečiní. Šablony a makra, pokud je organizace používá, musí být přepsány, aby byla zajištěna požadovaná funkcionalita nebo vizuální styl. Na trhu existuje několik derivátů kancelářského OSS, které mají plnou komerční podporu včetně čistě českých firem. V této metodice zmíníme několik nejvýznamnějších zástupců. OpenOffice a StarOffice V podstatě se jedná o téměř identické produkty, protože OpenOffice je postaven na StarOffice, který před léty koupila firma Sun Microsystems a uvolnila ho pro OSS komunitu, která jej dále vyvíjela. Zatímco OpenOffice je klasický OSS, který je k dispozici zdarma, StarOffice je i nadále prodáván společností Sun Microsystems za symbolickou cenu, která zahrnuje některé služby a produkty, které v OpenOffice nejsou. StarOffice má zabudovaný databázový systém Adabas, obsahuje filtry pro čtení formátů z Wordperfect, obsahuje některé proprietární fonty. Mezi nevýhody oproti OpenOffice patří lokalizace pouze do omezeného množství jazyků a nižší frekvence aktualizací. Obě aplikace si velmi dobře poradí se čtením proprietárních formátů, jak bylo uvedeno výše. Mezi nedostatky patří čtení heslem chráněných souborů a drobné problémy s grafickými objekty propojenými pomocí OLE.

30

OpenOffice i StarOffice mají zaveden vlastní Basic, který není kompatibilní s Visual Basicem v MS Office, a tak makra musí být přepsána ručně. Překlad maker je neopomenutelnou součástí nákladů na přechod na OSS. Na druhé straně je třeba zdůraznit, že díky nekompatibilitě se eliminovalo šíření tzv. makro virů. Společnost Sun Microsystems soustavně pracuje na překladu maker Microsoftu do formy čitelné StarOffice stejně jako implementaci Java interface. Volně dostupná verze OpenOffice zahrnuje v základním nastavení cca 25 různých jazykových mutací a pro většinu evropských jazyků je dostupný slovník. OpenOffice v současné době nenabízí adekvátní databázový balíček. ODBC a JDBC rozhraní k většině běžných aplikací zahrnují i OSS produkty. Obě aplikace jsou schopné provozu jak na platformě Windows, tak i GNU Linux, což z nich dělá velmi slibné aplikace vhodné pro plynulý přechod na OSS řešení. Koffice Tato aplikace má velmi intuitivní prostředí a zahrnuje řadu užitečných nástrojů, avšak podpora čtení formátů společnosti Microsoft je o poznání slabší než u OpenOffice. Koffice také nedisponuje makry, ale umožňuje skriptování. Gnome Office Tato kolekce programů byla vytvořena pro grafické rozhraní Gnome. Oproti běžným balíkům zahrnuje nástroje na kreslení atp. OpenOffice je nyní považován jako část Gnome Office, ačkoliv to nesplňuje veškeré Gnome standardy. Původní produkty, které zahrnovaly například Abiword (textový procesor) nebo Gnumeric (tabulkový procesor) poněkud zaostávají. Vizuální podobnost, která dokonale kopíruje starší verze proprietárních aplikací nenahradí nižší míru kompatibility, než která by byla očekávána. Cílem vývojářů Gnumeric byla snaha o dosažení maximální podobnosti s Exelem v otázkách funkcionality, což se podařilo především v US verzi. Stejně jako OpenOffice se však funkcionalita rozšířila a obě aplikace nyní nabízí daleko více funkcí než původní Excel. Gnumeric používá jako nativní formát .xls zatímco OpenOffice ukládá nativně tabulky do formátu na základě XML. V celkovém porovnání s OpenOffice Gnome Office zaostává, přestože obsahuje několik zajímavých řešení, které jsou vhodné jako doplnění určité funkcionality nového pracovního systému.

31

5.4.2. Poštovní aplikace Oblast elektronické pošty zahrnuje několik logických komponent, které jsou nutné pro zajištění celého procesu elektronické korespondence. Některé komponenty již předčily proprietární protějšky a také jsou často spojeny s dalšími produkty, které zahrnují antivirovou nebo antispamovou ochranu, které je věnován samostatný prostor v této metodice níže. MTA Mezi hlavní OSS MTA produkty patří Sendmail, Exim, Courier-MTA a Postfix. Samozřejmě existuje řada dalších produktů, avšak výše uvedené příklady poskytují nejširší možnosti použití. Sendmail,

který byl tradičně využíván Unixem i v OSS

projektech, má bohužel slabé

bezpečnostní záznamy a je docela obtížně nastavitelný. Ostatní uvedené příklady OSS poskytují dobré technické kvality a jsou snadno zaměnitelné. Důležitým faktorem pro rozhodování je však dostupnost technické dokumentace. Zatímco Postfix má dobrou dokumentaci pro začátečníky, Exim je lépe popsán na úrovni expertů. Exim i Postfix jsou zahrnuty v řadě OSS distribucí, přesto nemusí být nastaveny jako výchozí programy. Courier-MTA je součástí skupiny, která zahrnuje MDA, MAA a webmail balíček (sqwebmail). Každá část může být používána samostatně nebo v rámci skupiny. Neuvedeným produktem je Apache James mail server, který je napsán v Javě. Vzhledem k dlouhodobým zkušenostem a dobrým referencím je jako referenční model doporučován Exim. Důvodem je snadnější konfigurace a vyšší úroveň bezpečnosti než u Sendmailu. Administrátoři se však mohou rozhodovat individuálně podle jejich osobních priorit. Mailstore Většina administrátorů by chtěla mít raději centralizované úložiště e-mailů než lokální ukládání na pracovní stanice uživatelů. Pro tyto účely se hodí IMAP. V současné době existují tři nejrozšířenější OSS IMAP servery, které mají uvedené vlastnosti. UW-IMAP Tento server není doporučován pro svou nedostatečnou bezpečnost.

32

Courier-IMAP Snadno konfigurovatelný server, který dobře pracuje s Postfix a Courier-MTA, a je logickým článkem skupiny Courier. Jako úložní formát vyžaduje maildir. V minulosti se objevovaly potíže se zpracováváním některých S/MIME zpráv. Podporuje TlS (protokol pro standardní autentizaci a soukromí). Cyrus Tento server používá svůj vlastní formát pro úschovu e-mailů, který je sice podobný maildir, ale vyžaduje vlastní MDA. Podporuje TLS. Pro účely referenčního modelu byl vybrán Courier-IMAP bez MDA, které není zapotřebí, protože Exim je schopen zápisu přímo do maildir struktur a poštovní klient Evolution má své vlastní filtry. MUA Mezi OSS řešeními existuje celá řada textových i grafických MUA, které jsou použitelné. Pro ty, kteří jsou zvyklí používat Outlook nebo Outlook Express a chtějí používat něco velmi podobného je doporučením Thunderbird nebo Evolution. Evolution není pouze-mailový klient, ale zároveň i osobní manažer (PIM). Díky integrované LDAP může tato aplikace přistupovat ke jménu administrátora a načítat data v takové velikosti, v jaké jsou uložena ve schématu Evolution.

Evolution má zakomponovanou funkci „virtuálních složek“, které

umožňují uživateli definovat pravidla pro prohlížení jejich vlastních emailů různými způsoby bez nutnosti vytvářet kopie emailu, což by vedlo k nepřehlednosti při práci. Ve většině Linuxových distribucí jsou k dispozici programy kmail a sylpheed. Řada dalších aplikací podporuje IMAP a POP3, ale Evolution a Thunderbird jsou vývojově nejdál. V některých případech může být řešením migrace z mailového klienta na tzv. webové rozhraní. Jako pokročilý produkt je možné jmenovat SquirrelMail. Ve vývoji je OSS projekt Chandler, který zahrnuje pokročilé groupwarové funkce a stojí za to tento projekt sledovat. Anti-Virus Pokud jsou OSS systémy dobře nakonfigurovány, pak funkční rádius virů je výrazně limitován. Nicméně problémem může být přenos virů na uživatele, kteří používají jiné operační systémy a to zejména MS Windows. Mezi OSS antiviry je nejdále projekt ClamAV. Tento produkt je vhodné kombinovat s MTA produkty jako jsou Postfix nebo Exim, čímž ze zajistí chod antivirových filtrů.

33

Jiné nástroje Vedle problémů s viry existuje potřeba filtrovat spam a jiné škodlivé soubory. Spam Assassin je nejznámější a nejrozšířenějším programem spadajícím do kategorie „message analysis anti-spam tools“.

Anomy Sanitizer je konfigurovatelným nástrojem, který umožňuje

odstraňování příloh ze zpráv. Při odstraňování však dochází k narušení podpisu dokumentu, proto může být nasazen pouze v určitých případech. Fetchmail je programem, který ze vzdáleného úložiště mailů stahuje emaily nebo je předává jinému MTA. Nasazení nachází využití v případech, kdy administrátor nechce z bezpečnostních důvodů otevřít port pro příchozí email prostřednictvím standardního SMTP modelu. OfflineImap je nástrojem, který umožňuje ukládání emailů na centrální serveru a je synchronizován s úložištěm mailů na straně klienta. Propojení probíhá prostřednictvím IMAP standardním způsobem. Lokální strukturou je maildir. Tento nástroj může být velmi užitečný v případě, když odpojený IMAP je emulován kvůli MUA, který to nepodporuje. Whoson je program, který umožňuje POP metodu autentifikace vzdálených uživatelů před metodou SMTP. Používání tohoto programu je nutné, pokud uživatelé mají být schopni odeslat email přes administrátorské servery vzdáleně a SMTP autentifikace není k dispozici a administrátorský MTA je otevřen pro spojení z IP adres mimo důvěryhodný rozsah. Identifikované problémy a zkušenosti Uchovávání dat na LDAP serverech vyžaduje, aby bylo vybráno určité schéma. Schéma musí být kompatibilní s klienty, kteří požadují přístup k datům. Bohužel některé balíky přicházejí s schématy, které neodpovídají jejich potřebám. Součinnost jednotlivých produktů je třeba vyzkoušet před započetím migrace. Courier schéma podporuje také schéma Eximu, ale Courier IMAP ne atp.

5.4.3. Kalendář a groupware Tzv. „calendaring“ je špatně definovaným subjektem v rámci OSS, což je důsledkem absence otevřených standardů pro komunikaci mezi klienty a centrálním serverem. Přestože se v této oblasti řada produktů přiblížila např. Outlooku, některé důležité funkce stále zaostávají – např. synchronizace.

Produkty jmenované níže mohou být považovány za

webová řešení, pokud není uvedeno jinak. Všechny jmenované produkty jsou součástí nějakého groupware, který poskytuje další funkce. Většina groupware produktů je napsána v PHP nebo Perlu a tak může být upravena. Velmi dobrou reputaci má phpGroupware. Horde je pracovním rámcem pro další aplikace – Imp (web mail server), Turba (adresář), Kronlith (kalendář) aj. NullLogic je pouze v angličtině,

34

ale jiné jako phProject, Tutos, Twiggi a Twiki podporují celou řadu jazyků. OSS produkt, který yl původně proprietární, ale jeho majitelé jej otevřeli je OpenGroupWare, který se snaží být substitutem pro Exchange. Jiným OSS produktem je Kgroupware, který je vyvinut pro prostředí KDE. Popis k uvedeným produktům: Osobní kalendáře a agendy všechny uvedené produkty umožňují uchovávat osobní kalendář a úkoly. Skupinové kalendáře Tutos, Twiggi a NullLogic podporují skupinové kalendáře. Tutos je kontrolovatelný ze všech úrovní, které představují jak individuální, tak skupinové projekty pro všechny. NullLogic kalendář není možné mít privátní ve skupině. Organizování schůzek Mnoho produktů zahrnuje plánování zdrojů, které mohou být použity k plánování schůzek. Tutos umožňuje automatickou alokací lidí spolu s automatickým ohlašováním emailů těm, kteří nemají přístup do sdíleného kalendáře (externisty a jiné organizace). Program sleduje udělování souhlasu se schůzkou a umožňuje rozesílat mailem upomínky, pokud je to požadováno. phProject je podobný s tím rozdílem, že je schopen rozesílat také SMS ohlášky. NullLogic zvládá výše uvedené s výjimkou registrace místa pro schůzku. Nová rozšíření pro Thunderbird – Lightening umožňuje sdílení kalendáře a organizování schůzek. PDA synchronizace phProject je schopen se synchronizovat s PDA na platformě Palm. PDA synchronizace je součástí Gnome a Evolution, který je schopen synchronizace i s některými mobilními telefony.

5.4.4.Webové služby Webové prohlížeče Hlavními zástupci OSS prohlížečů jsou Mozilla, Galeon a Konqueror. Některé proprietární prohlížeče jako např. Opera nebo Netscape fungují i na platformě GNU/Linux. Typickým prohlížečem, který pracuje pouze v textovém režimu je Lynx, který je ideální řešení pro lidi s tělesným handicapem. Prohlížeče mají různé priority. Galeon je prohlížeč, který má stejné Gecko jádro jako Mozilla, ale klade větší důraz na velikost a rychlost. Oba prohlížeče velmi dobře podporují webové standardy a umí spouštět Javu a Jascript. Konqueror je webový prohlížeč, který pracuje v

35

prostředí KDE i jako souborový manažer. Webové servery Nepopulárnější OSS webovým serverem je Apache, který zaujímá přes 60% trhu a jeho podíl nadále roste. Oblíbenou je kombinace produktů, která je označovaná zkratkou LAMP (Linux, Apache, MySQL a PHP). Všechny komponenty jsou OSS a umožňují webovým stránkám přistupovat do SQL databází prostřednictvím PHP. Projekt Apache obsahuje celou řadu sub-projektů. Za zmínku je vhodné uvést projekt Jakarta, který umožňuje užívání serverové části Javy. Jakarta zahrnuje dva podprojekty – Tocat a Slide. Tocat je produktem pro Java servlets upravených do JSP standardů a umožňuje používání takových technologií jako např. IBM Websphere. Slide je Javovou implementací WebDAV umožňující správu obsahu (Content Management). Jinými OSS webovými servery jsou Zope a Tux. Zope byl navržen, aby poskytoval podporu dynamickému obsahu webu a je založen na objektově orientovaném modelu - Python. Je to zajímavý balík, který kombinuje tzv. systém řízení obsahu (Content Management System) s webovým serverem a šablonovým systémem v jednom. Zope mimo jiné podporuje modulární rozšíření (add-ons). Zope se požívá v multiserverových konfiguracích, kdy Apache obsluhuje statický obsah a funguje jako „cache-based“ akcelerátor pro aktivity Zope. Tux je produktem Red Hat, který je nyní nazýván „The Red Hat Content Accelerator“, a používá zvláštní kernel, který umožňuje velmi rychlou odezvu pro statické stránky. Nejrozšířenější server Apache obsahuje řadu modulů, které se pro specifické účely staví na jádro protokolového stroje. Portal a obsah Zope je platformou pro další projekty vyvíjející produkty pro správu obsahu. Příklady takových projektů jsou například ASWAD nebo Plone. Jboss je aplikační server postavený na Javě se silnou komunitou. Inspirativní seznam projektů pro správu obsahu je samozřejmě dostupný na stránkách vasemoznosti.cz.

5.4.5. Správa dokumentů Registrace a obnova Správa dokumentů může být použita jako forma řízení pracovních toků v organizaci. Touto problematikou se zabývá projekt ASWAD zmíněný výše nebo projekt WebDAV. Archivací elektronických záznamů se zabývají různé standardy, které však nejsou zcela jednotné. Například v Německu existuje standard nazývaný DOMEA (Disposition and Archiving of Electronic Records), který sice mimo Německo není příliš rozšířen, avšak byl adoptován

36

společností IBM ve spojení s SAP. Většina dokumentů ve vztahu k DOMEA (např. nalezených pomocí Google vyhledávání) jsou napsány v němčině. Sice existuje společnost FabSoft, která poskytuje podporu pro DOMEA na Linuxu na IBM mainframech, ale čistý OSS produkt, který by standard DOMEA podporovat zatím neexistuje. Správu dokumentů nabízejí některé dříve zmíněné groupware produkty jako např. Tutos, který umožňuje i správu různých verzí dokumentu, nebo NullLogic zahrnující jednoduchou možnost ukládat, indexovat a stahovat soubory. Nenabízí změnová řízení, ale mechanismus dotazů může být nastaven tak, aby umožňoval velmi přesné indexování. Spolupráce Tato funkce může být implementována ad-hoc jednoduchou výměnou dokumentů mezi lidmi. Výměna dokumentů může probíhat jednoduše prostřednictvím příloh v emailu nebo za pomocí mechanizmů, které jsou použity v rámci CIRCA. Spolupráce představuje odsouhlasení používaného formátu dokumentu zúčastněnými stranami. Většina lidí dnes používá rozšířený formát .doc společnosti Microsoft. I tento formát však má konstantní nevýhody, které představují zejména neustálou změnu tohoto formátu v jednotlivých verzích

aplikací MS Office. Zúčastněné strany tak musí mít

nainstalovanou stejnou verzi Office nebo se shodnout na konkrétní verzi tohoto formátu. Pro sjednocení spolupráce v rámci uzavřené skupiny je možné využívat standardizovaných formátů postavených na XML. Open Document Format vytvářený např. OpenOffice je oficiálně schválen Organizací spojených národů jako mezinárodní standard. Pro spolupráci je možné adaptovat také některý z modelů správy obsahu nebo pracovních toků, který byl popsán výše. Groupware Tutos umožňuje, aby dokumenty byly předmětem kontroly pouze jednou osobou v rámci určité skupiny. NullLogic a Twiki tuto kontrolu umožňují také. V této oblasti není nějaký referenční model.

5.4.6. Databáze Centrální databáze – aplikační OSS databázové systémy zahrnují MySQL, PostgreSQL a Firebird, které mají znatelně odlišné vlastnosti a tak i použití. Zatímco MySQL je databáze pro jednoduché nasazení např. pro webové servery a podobné aplikace. Vhodné je také nasazení v situacích, kdy převažuje přepisování dat. MySQL podporuje databázové procedury od verze 5, ale nepodporuje složité poddotazy.

37

PostgreSQL je plnohodnotný DBMS, který bez pokročilých rysů je srovnatelný s Oracle a DB2, a zvládá velmi velké objemy dat. Firebird je verze databáze Interbase, kterou firma Borland uvolnila pod OSS licencí. Většina kódu je společná s Interbase. Snahou jednoho z projektů je propojit OpenOffice a Firebird. Osobní databáze držené centrálně nebo lokálně Osobní databáze nejsou v OSS velmi dobře podporované a neexistuje přímý plně funkční ekvivalent pro Access (OpenOffice Base se vyvíjí velmi pomalu). Některé groupwarové balíčky jsou schopny nabídnout určitou funkcionalitu v oblasti za použití OSS SQL databází. V některých případech mohou běžní uživatelé používat pouze předdefinované dotazy (např. NullLogic), v jiných je možné vytvářet formuláře pro ukládání a vyhledávání dat. Databázová konektivita Většina DBMS produktů podporuje přímé APIs s C nebo C++ propojením. všechny nabízejí ODBC a JDBC konektivitu. Některé nabízejí také .NET konektivitu. Některé produkty jako např. Unix. ODBC poskytují konektivitu podobnou ODBC pro programy na platformách Unix a Linux. Výkon Výkon databáze závisí na velikosti tabulek a složitosti dotazů. Žádný z OSS se v této chvíli nemůže rovnat s výkonem, který poskytují některé proprietární řešení jako např. Oracle. OSS tak nemůže být nasazen v aplikacích jako například data warehousing, protože není schopen poskytnout tzv. distribuovanou databázi. Proprietární produkty typu Oracle, DB2, Ingres, Informix, Progress, Mimer nebo Sysbase jsou schopny fungovat na Linuxu, a tak mohou být vhodnou platformou v náročných řešeních, ve kterých OSS produkty nejsou dostačující. Také vývojové nástroje např. Oracle jsou podporovány i v Linuxu.

5.5. Aplikace – podskupiny 5.5.1. Operační systém V současné době existuje několik operačních systémů (např. OpenBSD, FreeBSD, NetBSD) včetně různých distribucí Linuxu, avšak většina lidí má pouze povědomí o „Linuxu“ obecně. Operační systém se skládá z kernelu (jádra), které běží v módu supervizora, paralelně k podporovaným programům, které běží pod kontrolou kernelu v uživatelském módu. Linux je

38

tento kernel, který však vyžaduje řadu podpůrných programů (ovladače, kompilery, zaváděcí programy atp.). Většina z těchto programů je poskytovaná GNU projektem společnosti Free Software Foundation, proto se k popisu názvu operačního systému používá spojení GNU/Linux. Linuxový kernel je poskytován jako balíček spolu s dalšími podpůrnými programy a aplikacemi prostřednictvím tzv. distribucí. Každá distribuce se může zásadním způsobem lišit, a tak by měla být věnována významná pozornost výběru vhodné distribuce dle jejích specifických vlastností. Některé z distribucí (Debian, Gentoo) nejsou připravovány žádnou komerční organizací, což pro uživatele znamená nulovou podporu (záštitu) ze strany konkrétní organizace. U komerčních distribucí (Red Hat, SuSE, Mandriva) si uživatel kupuje podporu. V obou případech se může zkušený uživatel spolehnout na podporu třetích stran – komunity. Velikost komunity je tak důležitým faktorem nejen pro „pomoc“ při instalaci, ale i pro další vývoj a aktualizace distribuce. Debian má pověst velmi seriózní a stabilní distribuce, jejíž kód je testován velkou komunitou po celém světě. Nevýhodou stabilních verzí je jejich zastarávání, protože za stabilní jsou považovány až poté, co jsou důkladně otestovány. Některé distribuce se tak zaměřují na nejnovější software, který však obsahuje chyby, ke kterým je nutné vydávat záplaty. U stabilních verzí z praktického hlediska hrozí větší pravděpodobnost, že nejnovější hardware nebude podporován. Gentoo je distribucí , která je šířena pouze jako zdrojový kód, což pro Administrátora znamená, že si může vybrat pouze ty binárky, které pro svou organizaci a hardware potřebuje. Vytváření vlastních binárek je časově náročné, ale jakmile jsou hotovy, jsou standardně dostupné. Podobným způsobem je možné upravovat jakoukoliv Open Source distribuci. Komerční distribuce mohou být vydávány s odlišnými balíčky (např. s komerčními fonty atp.) Takové distribuce jsou podporovány po omezenou dobu, avšak firemní verze mívají garantovanou podporu cca 5 let. Velkou výhodou proč přecházet na OSS je právě tato podpora, která zahrnuje i staré verze a na uživatele tak není vyvíjen tlak, aby musel přejít na novou verzi, jako tomu je u komerčního software. GNU/Linux v současné době nabízí velmi kvalitní konfigurační rozhraní i pro pracovní stanice, co z něj činí zajímavý nástroj pro široké použití. Přesto některé rozšířené OSS produkty nemusí být připraveny pro konkrétní distribuci nebo OS (např. Mozilla na OpenBSD). V oblasti nasazení na serverech je situace nanejvýš jasná díky statistikám o bezpečnosti OSS řešení. OpenBSD byl překonán pouze jednou za 6 let, což z něj činí

39

nástroj vhodný pro nasazení v situacích, kdy je vyžadována vyšší než průměrná míra zabezpečení. Serverové aplikace obecně běží velmi dobře na BSD platformách i Linuxu, ačkoliv mnohé byly původně napsány pro Linux a po té přeportovány. Proprietární software je však zpravidla dostupný pouze na Linuxu.

5.5.2. Uživatelská rozhraní Správce pracovní stanice (Desktop Manager) V současné době existuje několik možností v oblasti správy desktopů, jejichž výběr záleží na osobních preferencích uživatele. Gnome je grafickým rozhraním, které je podporováno společností Sun Microsystems a členy Gnome Foundation. Odlišnosti Gnome od KDE se dnes týkají především vizuálního zpracování než zásadního rozdílu v technické kvalitě, která zpočátku byla nakloněna ve prospěch KDE. Jazyková podpora Většina uživatelských rozhraní je již lokalizována do českého prostředí. K programům však nejsou plně přeloženy české návody a dokumentace, což však je problém i u některých proprietárních produktů.

5.5.3. Bezpečnost Při konfiguraci všech funkčních skupin musí být pamatováno na bezpečnost. Bezpečnost na úrovni software může být zajištěna pouze pokud existuje v rámci širšího bezpečnostního managementu. Kryptování dat Důvěrná data, která jsou šířena interní LAN by měla být kryptována. Citlivá data, která jsou posílána prostřednictvím internetu by měla být také kryptována. Toto kryptování může být realizováno prostřednictvím tzv. tunelování za použití produktů např. ssh nebo stunnel. Uchovávaná data Citlivá data, která jsou uchovávána na mobilních zařízeních by měla být na disku kryptována. V ideálním případě by měla být všechna data kryptována, ale protože tato procedura by nesla vysoké režie, tak bývá realizována jen ve specifických případech. Linux podporuje užívání některých bezpečných souborových systémů.

40

Autentizace Bezpečné metody jsou schopny identifikovat unikátní osobu nebo počítač, který je součástí nějaké komunikace s dalšími osobami nebo zařízeními. Tyto metody zahrnují podpisování a PKI infrastrukturu. Autentizace je prováděna např. oproti LDAP databázi prostřednictvím standardní výměny hesla. Autorizace Autorizace je obvykle součástí operačního systému nebo aplikačního kódu a jakmile je uvedena v provoz, tak by mělo být zcela zřejmé, kdo má přístup k jakému počítači a co může na něm dělat. Problém autorizace nemá jen administrativní rozměr, ale především ekonomický, který by neměl být podceňován. Antivirová kontrola Kontrola virů je primárně potřebná aby se zastavilo šíření viru na další subjekty nepoužívající OSS. Jedním z hlavních přenašečů virů je email, avšak není jediným, proto je nutné scanovat soubory, aby se zabránilo přenosu viru jinými prostředky. V této chvíli však není k dispozici odpovídající OSS. Pečlivá konfigurace souborových systému na straně serveru nebo pracovní stanice je základním předpokladem pro bezpečné užívání počítače. Jediné spustitelné programy by měly být nainstalovány na straně administrátora, přičemž zdroje programu by měl být dostatečně důvěryhodný. Proxy server Šíře inteligentního OSS pro proxy servery je k dispozici. Nejpopulárnějším produktem je squid, který ve spojení s produktem squidguard umožňuje zakázat přístup na určité webové stránky. Firewall Veškeré OSS operační systémy mají interní firewall založený na filtrování paketů. Tzv. statelful firewaly jsou ty, které spravují informace o běžících procesech a datových tocích skrz firewall a umožňují paketům, které jsou asociovány s daným datovým tokem, zatímco ostatní jsou odfiltrovány. Firewally , které nejsou „stateful“, prozkoumávají pakety podle svých vlastních měřítek a neudržují žádné záznamy o předchozích paketech. Pro protokoly typu ftp nebo telefonní H.323, které nepoužívají standardní připojovací prostředky, existují speciální rozšíření. Kvalitní firewally jsou např. iptables, který je zahrnut v Linuxu, zatímco ipfilter je zahrnut v FreeBSD. Packetfilter, jenž je zahrnut ve OpenBSD, má také velmi dobrou reputaci. Dobrou

41

praxí pro externí firewally je mít je zdvojené (fyzicky 2) tzn. firewally mezi připojením k veřejné síti a mezi interními servery. V rámci bezpečnosti není doporučováno jednofirewallové řešení.

5.5.4. Virtuální osobní sítě (Virtual Private Network) Open VPN K dispozici pro většinu Unixových platforem, které zahrnuje kryptování veřejného klíče, dynamickou kompresi pro „širokopásmový“ management a možnost pracovat s Network Address Translation. FreeSWAN Linuxová implementace IPSEC a IKE standardů, které operují v rámci speciálních routerů a jiných systémů. V otázkách nasazení FreeSWAN je třeba zvážit, zda jsou podporovány poslední standardy. CIPE Ačkoliv je tento nástroj zaostalejší oproti výše uvedeným (podpora veřejného klíče), existují verze jak pro Windows, tak pro Red Hat Linux.

5.5.5.Řízení Otázce řízení IT je třeba věnovat patřičnou pozornost. Přestože IT má být nástrojem jak zefektivnit procesy v organizaci, často je samo IT dezorganizované. Doporučován je modulární přístup, protože některé operace si Administrátoři obvykle řeší vlastním způsobem. Inspiraci v proprietárním řešení je možno hledat u IBM (Tivoli) nebo u Computer Associates (Unicenter). Správa uživatelů Správa skupin i jednotlivých uživatelů včetně správy hesel je možná např. prostřednictvím produktu Directory Administrator, který umožňuje LDAP. Správa konfigurace Ačkoliv dobře vytvořený centralizovaný model správy vyžaduje minimální lokální zásahy na straně tenkého klienta, jeho překonfigurování úplně od začátku může připadat v úvahu při systémových up-date nebo organizačních změnách. V těchto případech je vhodné mít připraveny nástroje, které zefektivní a urychlí tyto procesy.

42

Manuální údržba konfigurace Přestože Administrátoři mohou udržovat konfigurační up-date manuálně, nedochází k úplné eliminaci synchronizačních chyb, zejména překlepů v textových konfiguračních souborech. Cfengine GNU konfigurační stroj (Configuration Engine) automatizuje vzdálenou konfiguraci zasíťovaných klientů. Podporuje to širokou skupinu různých klientů ve skupinách s minimálními nároky na nastavení. Samostatní agenti na klientech mohou udržovat textové soubory, síťová rozhraní, propojení se soubory a oprávnění nebo připojení souborového systému a dočasného uložení souborů. Základní kroky, které mohou být automatizovány prostřednictvím cfengine jsou např.: kontrola a konfigurace síťového připojení, editování textových souborů, mazání „junk files“ vytváření symbolických linků a příkazů, kontrola na nastavení práv a vlastnictví souborů, systematické připojování souborového systému, kontrola přítomnosti důležitých souborů a souborových systémů, kontrolované vykonávání uživatelských skriptů nebo příkazů, kontrolované spouštění uživatelských skriptů a příkazů. Systémový konfigurátor Systémový konfigurátor je součástí tzv. System Installation Suite a je používán System Installer. Napříč většinou distribucí může nastavit a udržovat spoustu komponent, které mají na starosti např. síťování, ukládání, časová zóna nebo bootovaní. Software management Tato část pojednává o údržbě klientů od počátečního nastavení na nový hardware po průběžné aktualizace software, konfigurace, a také o technologiích, které jsou pro softwarový management k dispozici. Instalace systému Instalace systému představuje úvodní nastavení software a konfigurace, která je nezbytná pro údržbu počítače. Továrně vyrobené počítače nemusí mít vůbec žádný operační systém nebo jsou dodávány s předinstalovaným software. Starší počítače, na kterých je nainstalován starší software, mohou být také použity s tím, že na něm bude nainstalován nový systém. První úlohou systémového instalátoru

je „nabootování“ cílového počítače. U nových

počítačů s neinicializovanými disky je nutné se ujistit, že je možné bootovat alespoň jednou jinou metodou než z hard disku. Nejstarší metodou bootování je z floppy disku, avšak na nových počítačích (zejména noteboocích) se floppy disk nemusí cfengine vyskytovat,

43

protože diskety jsou pomalé, nespolehlivé a poskytují na dnešní dobu velmi omezený prostor pro systémový instalační software. Většina počítačů vyrobených před rokem 1997 poskytuje bootování z CD-ROMu jako emulaci floppy disku. CD nebo DVD jednotka pochopitelně umožňuje umístit na médium vedle bootovacího software i další software. V současné době je však nejrozšířenější bootování po síti, přestože ne všechny síťové karty nebo BIOS tuto možnost umožňují. Většina počítačů vyrobených po roce 1998 by však měla tuto možnost umožňovat. Instaler musí přistoupit ke konkrétnímu instalačnímu médiu, které obsahuje software vyšší úrovně, jakmile došlo k nabootování. Tento software je zpravidla uložen buď na vyměnitelném médiu nebo lokálním serveru. Na CD nebo DVD může být tzv. „snapshot“ natavení všeho statického software, což je vhodné v situacích, kdy se předpokládá, že se software nebude jen tak měnit. V obecné rovině lze síťovou instalaci považovat za mnohem flexibilnější, rychlejší a umožňuje nainstalovat daleko větší objem dat. Navíc umožňuje několikanásobnou paralelní instalaci na několika klientech současně. Systémový instaler přenáší software z vybraného média na lokální disk cílového počítače a připravuje jej na nabootování. Nabootování obsahuje detekci hardware, ověření diskové kapacity a konfiguraci např. síťových nastavení. Standardně lze instalace rozdělit do několika metodických postupů: •

Manuální instalace

Manuální instalace je nejjednodušší instalací, kterou provádí systémový Administrátor. Software je obvykle uložen na vyměnitelném médiu včetně bootovacího disku. Protože výběr balíčku, rozdělení disku na partice, konfigurace hardware a síťových nastavení musí být nastaveno manuálně, tak tento proces je časově náročný a nese riziko výskytu lidské chyby. Většina distribucí Linuxu má svůj vlastní instalační program (anaconda – Red Hat, YAST – SuSE, atp.). •

Klonování obrazu

V případě, že pracovní skupina bude používat téměř identický software, je možné vytvoření „vzorového klienta“ (golden klient), který slouží jako vzor pro replikaci. Některé systémy např. Knoppix umožňují oficiálně vytvořit vzorového klienta, který pak bude instalován na další počítače. Konfigurace a uživatelská nastavení mohou být přidána pomocí skriptů před nebo po instalaci. Protože může být kopírován celý souborový systém, je tato možnost zdaleka efektivnější než kopírování jednotlivých souborů. Konfigurace neidentických klonů je méně 44

efektivní a vyžaduje patřičné administrátorské znalosti. •

Plně automatická instalace

Tzv. Fully Automatic Instalation je schopen např. Debian nainstalovat automaticky. Balíčky software jsou dostupné na webových stránkách Debianu nebo lokálním mirroru pro urychlení přístupu. Instalační kernel může být nabootován např . ze sítě, ale i floppy disku. Ačkoliv FAI bylo původně navrženo pro identickou replikaci počítačů, cfengine je použit pro systémovou konfiguraci, čímž je dosaženo rozšíření původních možností. •

Obraz systému

Tzv. System Imager poskytuje instalaci systému, konfiguraci a údržbu pro rozsáhlejší sítě počítačů, ideálně s identickým (podobným) hardware, napříč různými distribucemi. Bootovat může opět z floppy disku, CD-ROMu nebo PXE síťových serverů. Debian i Red Hat jsou pouze dva z příkladů distribucí, ačkoliv by System Configurator software měl být podporován již ve všech GNU/Linux distribucích. Vzorový klient je manuálně nainstalován a nakonfigurován. Poté je jeho souborový systém přenesen na „image server“ jako mirror, ze kterého se pak ostatní počítače instalují. V případě, že je vzorový klient aktualizován, pak se tyto aktualizace promítnou i na replikovaných počítačích prostřednictvím programu rsync. Ačkoliv rsync posílá po sítí i minimální rozdíly, vyžaduje dostatečně velkou paměť, aby synchronizace probíhala bez problémů. System Imager je vhodným řešením pro cílové klienty s identickým nebo velmi podobným hardware. •

Red Hat Kickstart

Kickstart je automatický instalační software distribuce Red Hat, který opět může být instalován ze všech výše uvedených médií. Anakonada instaler nabízí textové nebo grafické rozhraní a může být interaktivní nebo plně automatizované konfiguračním souborem. Obecné volby instalace mohou být nastaveny v konfiguračním souboru a rozšíření dodány prostřednictvím skriptů před nebo po instalaci. Kickstart může být používán pro různý hardware, protože má velmi dobrou rozpoznávací schopnost a inteligentní konfiguraci. Kickstart může být upraven tak, aby mohly být zahrnuty i jiná rozšíření než jen tak, která poskytuje přímo Red Hat. Údržba software Instalace software nezůstávají statické během svého životního cyklu. Aktualizace software jako např. bezpečností up-date nebo opravy chyb budou nepochybně uvolněny až po úvodní instalaci. Také odstranění konkrétního balíčku nebo jeho přidání musí proběhnout bez

45

nutnosti reinstalovat celý systém znova. Kdykoliv je to možné aktualizace by měly být raději taženy nějakým cílem než tlačeny. Rozhodnutí tažených aktualizací by měly být dělána automaticky počítačem (buď serverem nebo desktopem) poté, co se sám verifikuje u master serveru. Aktualizace by tak neměly být pod kontrolou uživatelů. Tímto přístupem lze dosáhnout toho, aby všechny počítače používaly stejnou verzi určitého software. Údržbu je opět možné provádět několika způsoby: •

Manuální údržba software

Systémoví administrátoři mohou udržovat software manuálně, což představuje zalogování se do konkrétního vzdáleného počítače, nakopírování aktualizačních balíčků a jejich nainstalování je prostřednictvím nativního správce balíčků. Přestože tento postup poskytuje Administrátorovi kontrolu nad svou prací, je tato metoda náchylná na chyby a ve větším měřítku je téměř neproveditelná. Některé distribuce nabízejí aktualizační nástroje, kterými je možné udržovat jejich standardní balíčky, ale i tak jsou nutné manuální zásahy. •

Ximian Red Carpet

Red Carpet je volně dostupný software pro aktualizace z Ximianu. V současné době však bezpečně obsluhuje přístup více softwarových kanálů včetně distribučních aktualizací (např. Mandriva, SuSE atp.) Program umožňuje snadnou vzdálenou administraci a automatizaci, takže centrálně může být spravováno velké množství klientů. Bohužel však neumožňuje aktualizace kernelu nebo architektury. Red Hat nabízí také proprietární serverové řešení (Red Carpet Enterprise), které může být použito pro administrátorské zvládnutí velkého množství software. Neměl by být používán grafický interface, který uživatelům dává možnost kontrolovat aktualizace. Prostřednictvím skriptů by měly být aktualizace prováděny automaticky. •

Red Hat Enterprise Network

Za zmínku stojí inspirativní proprietární řešení distribuce Red Hat, které prostřednictvím produktu Satellite Server umožňuje plnou úpravu aktualizací a errat. všechny servery podporují jejich standardního Update Agent pro distribuci aktualizací. •

Debian APT

APT je sadou nástrojů dodávaných s distribucí Debian, která umožňuje automatizované aktualizace nainstalovaného software. APT je schopný zkontrolovat závislosti mezi softwarovými balíčky, které jsou nainstalovány nebo jsou k dispozici v repozitáři, APT je nakonfigurováno tak, aby automaticky nainstalovalo aktualizace z dostupných repozitářů.

46

Organizace mohou vytvořit a udržovat vlastní repozitáře nebo mohou veřejné repozitáře doplňovat o jiné zdroje software. APT pracuje na RPM operačních systémech (Red Hat, Mandriva). Management hardware a monitoring systému Hardware může být monitorován na chyby a potenciální selhání například prostřednictvím hard disků podporujících SMART (Self-Monitoring, Analysis and Reporting Technology) technologii a jiný detekční software či hardware. Hardware i software může být sledován i po stránce vytížení kapacit a servisu, který poskytuje. •

MRTG a Snmpd

Multi-Router Traffic Grapher je monitorovacím nástrojem, který byl původně navržen aby sledoval a zobrazoval využití kapacity síťových linků. Časem však byl upraven do komplexního nástroje, který umožňuje sledovat vytížení procesoru, pamětí a síťových služeb včetně objemu zpracovaných emailů, obsloužených webových stránek nebo systémovou teplotu či rychlost otáček ventilátoru a dalších ukazatelů. Simple Network Management Protocol Daemon je systémový management serveru, který může být spouštěn na každé pracovní stanici v rámci organizace. Poskytuje informace o systémovém managementu klientům (obvykle centrálnímu klientu s agregovanými statistikami z celé skupiny počítačů. MRTG může působit právě jako takový klient, který poskytuje tuto funkci. •

Nagions

Nagions je nastavitelný host, který umožňuje správu sítě a monitoring. Je schopen monitorovat síťové služby a provádět různé obnovovací procedury v situacích, kdy odhalí, že služba je nedostupná nebo má nějaké problémy. Zahrnuje např. spouštění obnovovacích skriptů nebo informování systémových Administrátorů o problému. Nagios také může poskytovat sestavy a zprávy o současném a minulém stavu služeb, které jsou monitorovány. •

Smartd

SmartMonTools zahrnují daemona, který se nazývá smardt a byl navržen, aby monitoroval SMART

funkce moderních hard diskových jednotek. Od té doby, co tyto jednotky jsou

nejběžnější komponentou, která v moderním počítači selhává, SMART sleduje parametry jednotky, které mohou včas varovat systémového administrátora o potenciálních chybách před tím, než se skutečně stanou. smardt je navržen tak, aby byl schopen obdržet tato varování a podniknout nějakou akci (obyčejně informování systémového administrátora).

47

Správa tisku •

LPRng

LPRng je vyvinuto na základě BSD standardu lpr/lpd. Obsahuje to řadu vylepšení, které jsou robustnější a snadnější na ovládání než originální produkty a navíc LPRng je zaručeně bezpečný. Do nedávna to byla jasná volba pro správu tisku. V dnešní době je velmi rozšířen CUPS. •

Common Unix Printing System

CUPS je navržen jako podnikový tiskový systém Unixu. Je postaven na standardním Internet Printing Protocol (IPP) a zahrnuje funkce prohlížeče, což umožňuje, aby jména a vlastnosti tiskáren byly automaticky distribuovány v síti. CUPS také zahrnuje webové uživatelské rozhraní pro administraci a konfiguraci tiskáren. Ovladače jsou dostupné pro většinu běžných tiskáren. •

Kprint a GnomePrint

KDE a Gnome mají své vlastní tiskové subsystémy, které jsou schopné obsluhovat uživatelské aplikace s nejčastěji používanými tiskovými systémy zahrnujícími LPRng a CUPS.

5.5.6. Backup a recovery Očekává se, většina uživatelských i administračních dat je očekávána na jednom nebo více serverech. Je nezbytné, aby byly prováděny inkrementální zálohy, aby bylo možné nalézt tyto zálohy nebo konkrétní soubory a obnovit jak individuální soubory tak celé souborové systémy. Zálohy uživatelských dat se zdá být snazší v Unixu a OSS systémech, a pak až ve Windows, protože uživatelské soubory dat jsou obvykle obsaženy v jednom adresáři. To je další z oblastí, ve které proprietární produkt jako např. Legato může být vyžadován pro nasazení ve velkých organizacích. Dump and restore Tyto programy jsou dodávány jako součást většiny distribucí a jsou někdy používány spolu s tar a cpio v upravených skriptech pro zálohování a obnovu jednotlivých počítačů. Amanda To je klient server produkt, který je navržen, aby byl schopen zálohovat několik počítačů na jedno zařízení. Umožňuje to zálohovat počítače pod Windows pomocí Samba.

48

5.5.7. Jiné služby Časové servery Ve vysoce zasíťovaném prostředí je nezbytně nutné, aby všechny počítače – servery i pracovní stanice používaly stejný aktuální čas. Jeden nebo více serverů jsou navrženy jako tzv. master servery, které získávají čas buď z připojených hodin nebo z externího časového serveru na internetu. všechny další počítače jsou tzv. slaves, které se synchronizují oproti těmto počítačům. Synchronizování času může být prováděno buď chodem ntp na počítačích, což umožňuje docela snadno udržet počítače v síti synchronizované do jedné sekundy. Chrony je alternativou k ntp. Má to několik vlastností, které z něj dělají nástroj vhodnější pro vyšší NTP nody, zatímco ntp se více hodí pro nižší NTP nody, které mohou vyžadovat rozhraní přímo na GPS přijímače nebo atomové hodiny. Existují i OSS produkty pro Windows, které jsou využitelné ve smíšeném prostředí jako např. Automachron a nettime. Servery síťové infrastruktury Tyto služby jsou nezbytné, pokud má fungovat síť na protokolu TCP/IP. •

Routing

Routery umožňují rozdělit velké sítě do menších propojených sítí. Routery mají za úkol nasměrovat pakety z jedné subsítě do jiné a umožnit jim, aby se dostaly na místo jejich určení. Stavění routerů vyžaduje dobrou znalost základních protokolů a mnoho administrátorů se obvykle přiklání k proprietárním routerům. Mezi pokusy o OSS řešení se pokoušely projekty GNU Zebra nebo Bird (MFF, Karlova univerzita), oba projekty se však již nevyvíjí. •

Domain Name System

TCP/IP síť potřebuje prostředky pro překlad IP adres do lidsky zapamatovatelných doménových jmen a opačně. DNS je protokol dohromady s počtem vzájemně komunikujících serverů obsahujících data. DNS je základem pro fungování Internetu. Existuje spousta programů, jak postavit vlastní DNS servery zahrnující např. BIND, MyDNS a MaraDNS. Nejrozšířenějším je BIND. •

DHCP

DHCP je protokolem, který umožňuje počítačům získat jejich síťové detaily od okamžiku nabootování z centrálního serveru/ů. DHCP umožňuje efektivní používání IP adres, které

49

podle podle potřeby rozmístí. Také umožňuje centrální administraci spousty globálních adres jako jsou „gateways“ a „name servers“ Hlavní produkt zahrnuje klient server aplikaci. Klient musí běžet na všech participujících počítačích Oba produkty jsou součástí většiny distribucí Linuxu.

50

Souborové servery Síťové souborové servery umožňují počítačům připojeným k síti přistupovat k úložišti souborů na vzdáleném počítači. •

NFS

Toto je takřka standard, jež je používán po mnoho let. Běžně implementovaný podčlánek neposkytuje spolehlivé zabezpečení. Pro bezpečné nasazení je možné počítat s některými komerčními Unix variantami. NFS se sestává ze serveru, který exportuje soubory z počítače, na kterém běží, na klienty, kteří jsou připojení k dalším připojeným počítačům. Existuje kontrola (autentizace), pomocí které mohou počítače být omezeny na ty, které mohou k souborům přistupovat. Problémem všech síťových souborových systémů je pochopitelně nedostupnost souborů v případě výpadku sítě. Řešením může být distribuovaný souborový systém, který je popsán níže. NFS je standardní součástí většiny Linuxových distribucí. •

Samba

Samba je produktem, který implementuje SMB protokol Společnosti Microsoft. Tento produkt je nedílnou součástí systémů OSS a Windows, které mají být propojeny prostřednictvím sdíleného úložiště souborů. •

Netatalk

Netatalk je řešením pro uživatele Apple Macintosh. •

OpenAFS, CODA a Intermozzo

Tyto produkty implementují distribuovaný souborový systém k různým stupňům. S takovým přístupem k souborům je možné pokračovat v práci se soubory i v případě, že síť spadne, protože lokální uzly se chovají jako by byly připojeny. Toto není triviální problém a uvedené produkty je řeší různými metodami. Tato skupina souborového systému je skutečně nepostradatelná v případě laptopů nebo přenosných počítačů. Jiným případem, kdy je využita obdobná funkcionalita, je periodická synchronizace lokálního úložiště s centrálním serverem. Directory services Nejrozšířenějším adresářem poskytujícím jména a adresy pro rychlé vyhledávání je LDAP. Tento otevřený protokol je implementován v řadě produktů jako například Evolution nebo OpenOffice. LDAP pracuje s definicemi dat, které jsou nazývány schémata a tato schémata

51

mohou být upravena administrátorem. Bohužel ne vždy jsou schémata používaná různými aplikacemi kompatibilní, což znamená, že se musí hledět na požadavky, které jsou od adresáře očekávány. OSS aplikace OpenLDAP může být snadno propojena s různými databázemi. Většina groupware řešení poskytuje nějakou formu adresáře avšak ne všechny jsou kompatibilní s LDAP. Adresáře jsou obsaženy i v mailových agentech. Podpora Terminálová emulace Použitím xterm s vhodným TERM prostředím je možné dosáhnout emulace většiny terminálových typů např. VT220, VT100 nebo x3270. „Stránkové“ emulátory poskytují proprietární řešení. Vzdálené displeje a emulace jsou popsáni podrobněji níže.

52

6. Migrace aplikací – přehled Jakmile je vytvořen seznam aplikací je možné jej seskupit do několika kategorií. Proprietární aplikace s OSS ekvivalenty Již zmíněné aplikace typu Office, Lotus SmartSuite, WordPerfect nebo Photoshop je možné do jisté míry nahradit substituty ze světa OSS, pokud zrovna splňují očekávanou kompatibilitu. Proprietární aplikace, které běží v OSS prostředí Některé aplikace jako např. Acrobat Reader mají své verze pro OSS prostředí. Pokud své OSS verze nemají, pak je nutné hledat ekvivalentní produkty – viz výše. Software, ke kterému může být přistupováno přes vzdálený display Aplikace mohou být spouštěny na serveru a zobrazovány na obrazovce pracovní stanice, jako u tenkého klienta. Produkty jako jsou Windows Terminal Server, Citrix nebo Graphon umožňují aplikacím, aby běžely na serveru s Windows v multiuživatelském režimu. To znamená, že aplikace, která je určena k tomu, aby byla používána na pracovní stanici, může být spouštěna na serveru. Tato procedura vyžaduje součinnost třetích stran (prodejců), protože ke spuštění je nutné přistupovat ke zdrojovému kódu. Nejsofistikovanějším ze zmíněných produktů je Citrix, který má svůj vlastní protokol (ICA), který funguje i v pomalých sítích. Umožňuje provozovat serverovou farmu, ve které je zátěž rozdělena rovnoměrně a umožňuje spoustu dalších nastavení. Volní ICA klienti mohou běžet pod GNU/Linux. všechny tyto produkty jsou však závislé na proprietárním software. Je zapotřebí Windows server licence, Citrix licence a Windows Terminal Server licence, pokud je používán. Dále Client Access Licences budou zapotřebí pro každý desktop užívající software. The Citrix licence je založena na uživatelích, takže tato filozofie může být levnější alternativou v případě, že je spousta uživatelů, kteří potřebují přístup k aplikaci. Citrix má také řešení pro pro Unixové aplikace, aby mohly být standardně transportovány a zobrazovány na obrazovce klienta. Windows Terminal Server poskytuje podobnou funkcionalitu jako Citrix s výjimkou, že používá vlastní RDP protokol, který za ICA zaostává, přestože byly mnohé rozdíly setřeny. Obě řešení pochopitelně nebudou poskytovat uspokojivou odezvu pokud budou servery výkonově podhodnoceny a síť nebude dostatečně rychlá. Tarantella je produkt, který má místo mezi pracovní stanicí a aplikačním serverem.

Tento produkt využívá vlastní

53

proprietární protokol AIP, který je vhodný pro pomalé sítě. Agreguje výstupy z aplikací běžící na Citrix, Windows, Unix a jiných mainframes a posílá výsledky na prohlížeč pracovní stanice. V oblasti bezpečných propojení mezi serverem a pracovní stanicí působí CrossOver Office od CodeWeavers, který má však vysoké nároky na rychlost sítě. VNC je OSS produktem vyvinutým společností AT&T, jehož cílem je zobrazit uživatelské místo na jiném počítači. Řešení se skládá z serveru a klienta jak pro Windows, tak i pro Linux. VNC umožňuje aplikacím, aby byly spouštěny v jednom prostředí a zobrazovány v jiném. Produkt využívá vlastní otevřený protokol RFB, který není tak efektivní jako ICA nebo AIP, takže vyžaduje

rychlost sítě nad 100Mb/s, aby pracoval dobře. Také Windows VNC

server se nedá výkonnostně srovnávat s Unixovou verzí, a tak má vyšší nároky na výkon serveru. VNC je použitelné v situacích, kdy administrátor potřebuje na krátkou dobu převzít kontrolu nad pracovní stanicí a větší odezva bude akceptovatelná. Software, který běží pod emulátory Pokud není možné provozovat aplikaci žádným výše uvedeným způsobem, pak je možné emulovat původní operační prostředí prostřednictvím emulátoru. Všechna tato řešení však ovlivňuje licenční politika, protože emulace vyžaduje provoz několikanásobných kopií proprietárního produktu (nejen aplikace, ale i operačního sytému!). V praxi se používají dva typy emulací: •

Hardwarová emulace

Emulátory umožňují normálnímu PC, aby se chovalo jako virtuální počítač, což umožňuje spouštět aplikace jiných operačních systémů na OSS platformě. Hardwarová emulace vyžaduje plné licence emulovaného proprietárního software, případně včetně licence za emulátor. VMware není vyloženě emulátor, poněvadž umožňuje procesům, aby byly přímo předávány procesoru, což ale vyžaduje x86 architekturu. VMware je proprietární řešení, které spotřebovává podstatnou část výkonu počítače. Win4lin je řešení podobné VMware a také je proprietárním produktem, avšak méně nákladným. Z bezpečnostních důvodů není doporučováno nasazení komerční distribuce Lindows, které tento emulátor zahrnují ve firmách. Bochs je zástupcem OSS emulátoru, který dokáže emulovat procesory od i386 až po 686, a dokonce dokáže i emulaci pro 1, 2 nebo 4 procesory. Bochs je napsán v C++ a umožňuje ve svém emulovaném prostředí běh operačních systémů jako je Linux, DOS a většina verzí Windows.

54

•

Softwarová emulace

Softwarová emulace umožňuje programům napsaným v proprietárním prostředí, aby byly spouštěny přímo v OSS operačních systémech. Jakékoliv systémové volání je namapováno na ekvivalentní OSS rozhraní. Kopie proprietárního systému (a tak i licence) není zapotřebí. Wine umožňuje aplikacím napsaným pro Windows, aby byly spouštěny v prostředí Linuxu. Bohužel Wine není schopen poskytnout všechna systémová volání, a tak ne všechny aplikace pro Windows budou v Linuxu funkční. Projekt Wine je doplňován o výsledky proprietárního produktu CrossOver Office, která je dostupná i v serverové verzi a může poskytnout podobnou funkcionalitu jako Citrix. K provozu proprietárních aplikací je nutná licence. Nemusí být licence na operační systém, avšak některé licence aplikací to mohou požadovat, proto je nutné se seznámit s konkrétní licenční politikou! Software, který může být rekompilován pod OSS Pro některé aplikace, napsané na míru pro určitou organizaci, je možné převést kód do verze pro OSS platformu. Ve skutečnosti není problém převést jakýkoliv k do OSS prostředí, avšak kód může vyžadovat konkrétní systémové knihovny pro grafické prostředí atp., což znamená, že k musí být manuálně přepracován tak , aby pracoval s odlišnými systémovými prostředky. •

Java

Pokud byl software v Javě napsán v souladu se specifikací Java, pak by software měl běžet bez problémů. •

Visual Basic

Pro přenos produktu z Visual Basic do Kylix pod Linuxem je možný za pomocí proprietárního produktu DeLux. Jinou možností je převést Visual Basic do .NET a vytvořit CIL kód. Mono OSS projekt umožňuje spouštět tento kód v prostředí Linuxu. •

C#

Podpora pod Linuxem je velmi dobrá v rámci Mono projektu, který obsahuje interpreter, který umožňuje, aby proprietární vývojové nástroje mohly běžet na Linuxu beze změny. Mono projekt a použití .NET vývojového prostředí je velmi čilou OSS aktivitou. •

Pascal a Delphi

Pascal je jazykem, který v dnešní době není příliš využíván, ale je důležitou komponentou

55

pro kódování v Delphi. Borland disponuje s ekvivalentem Delphi pro Linux, což je již zmíněný Kylix, který má identickou syntaxi i podporu s Delphi. •

C a C++

Programy napsané pro ANSI standardy mohou být snadno rekompilovány pouze za předpokladu, že používají stejné knihovny. Nesoulad může být v některých situacích řešen prostřednictvím kompilace kódu s Winelib, což je součástí výše zmíněného Wine projektu.

6.1. Scénář č. 1 – Windows Administrace má jeden nebo více vzájemně propojených pracovních skupin na platformě Microsoft Windows (pokud je psáno o konkrétní verzi operačního systému Windows, pak tak bude vysloveně uvedeno). Kódování je uvedeno na příkladu distribuce Red Hat.

6.1.1. Plánování migrace Je velmi pravděpodobné, že důsledné naplánovaní přechodu na OSS ve větší organizaci může představovat několikaměsíční práci i několikaletou práci. Během této doby musí být nachystány plány školení a krizové plány, které zohledňují výsledky pilotního testování.

6.1.2. Oblasti působnosti Oblasti působnosti platformy Windows se pro účely tohoto materiálu dají rozdělit na pracovní skupiny a domény. Zatímco pracovní skupiny kooperují v síti bez zvláštních bezpečnostních požadavků a sdílejí data maximálně chráněná nějakým heslem, doménový model zahrnuje kontrolery, kteří koordinují uživatelská jména a hesla. Migrace z pracovní skupiny tak představuje pouze „manuální“výběr souborů, které v podstatě nemají koncept vlastníka souboru. U doménového modelu jsou změny realizovány prostřednictvím i několika serverů (poskytují kapacity pro sdílení zátěže). Souborové servery (s funkcemi Primary Domain Controller nebo Backup Domain Controller) poskytují uložení profilů (uživatelské pracovní stanice, dokumenty a nastavení), ale mohou obsahovat také sdílení úložiště nebo tiskové služby. V dobře řízených doménách jsou uživatelé obyčejně informováni o tom, aby své soubory ukládali do domovského adresáře a důležitá data nedrželi na individuálních počítačích. V případech dobře řízeného prostředí je migrace velice snadná, poněvadž systémový administrátor přesně ví, kde jsou data ukládána.

56

Od doby Windows 2000 existuje tzv. Active Directory model, který byl původně určen pro efektivní řízení velkého množství uživatelů. Tento model zahrnuje myšlenky jak DNS tak i LDAP. Souborové servery udržují nejen domácí adresáře, ale i související profily, takže migrace v ohledu nalezení konkrétních souborů není náročná. Navíc LDAP umožňuje využit několik možností migrace. AD servery mohou např. udržovat uživatelská jména a hesla pro OSS servery a klienty. Toto řešení je možné např. v situacích, kdy na OSS přešla jen část uživatelů a standardní proces management musí zůstat ještě zachován (do doby než bude vytvořen nový atp.). Přehled možných směrů migrace První možností je předávat OSS počítače k existující Windows doméně a postupně přesouvat data a uživatele a časem odstranit proprietární servery. Samozřejmě je možné migrovat klienty a servery samostatně. Přidáním serverů k doméně Windows je jednou z nejrychlejších cest jak začít profitovat z OSS řešení. Kombinace Linuxu se Samba poskytuje velice levné řešení pro souborový nebo tiskový server, který může být používán v prostředí Windows bez jakýchkoliv změn v existujícím prostředí. Provozování OSS klientů v prostředí Windows představuje nízké riziko z hlediska koexistence, protože nejsou vyžadovány žádné změny na straně serveru. Tato možnost je vhodná v situaci, kdy pouze malý počet uživatelů používá OSS řešení v jinak kompletním prostředí Windows. Druhým modelem je paralelní vybudování OSS infrastruktury a migrovat uživatele a jejich data ve skupinách. Interakce mezi novým a starým systémem by byla minimální. Tento přístup je jednodušší než provoz smíšeného systému, ale vytváří „bariéru“ mezi uživateli v novém a starém systému. Obě cesty sumarizuje diagram uvedený níže. První model představuje užší spolupráci mezi novým a starým systémem během přechodu, ale vyžaduje precizní plánování a implementaci.

57

Model 1 Klienti Pilotní odzkoušení pracovních stanic na OSS

Test s klienty na OSS

OSS řešení

Doména NT

Přidání OSS/Samba serverů

Přesunutí uživatelských dat na OSS servery

Nahrazení NT domény s LDAP

Servery Model 2

Doména NT

Odstranění starého systému

OSS řešení Paralelní doména OSS

Přenesení dat a uživatelů ve skupinách

V raných stádiích migrace je nutné počítat s fází koexistence, kdy oba systémy musí být schopny přenosu stejných dat. Pro tento provoz je nutné vzít v potaz nejen technické řešení, ale také nutnou technickou infrastrukturu, která je zapotřebí tuto koexistenci zabezpečit.

6.1.3. Obecné požadavky Existuje spousta podobností mezi současnými proprietárními systémy a OSS, který by je mohlo nahradit. Zejména grafická rozhraní mají tendenci se velmi podobat zažité vizualizaci, což eliminuje vážnější problémy s přeškolením uživatelů. Nicméně uživatelské zaškolení bude určitě zapotřebí. Vedle vizuální podobnosti totiž existují podstatné odlišnosti zejména v systémové administraci, která vyžaduje důkladné zaškolení. Automatizace prostřednictvím 58

skriptů je důležitou předností OSS řešení, a Proto je nutné, aby ji administrátoři byli schopni využít. Vedle odlišností v oblasti managementu procesů existují rozdíly ve službách, které jsou poskytovány. Uživatelská jména a hesla Uživatelé počítačů se identifikují prostřednictvím svého uživatelského jména a hesla. V některých administracích se rozšiřuje využití tzv. smart karet nebo jiných kryptografických zařízení, které poskytují vyšší stupeň ověření identity uživatele. Někteří uživatelé strukturují uživatelská jména tak, že obsahují informace o uživateli. V případě, že se jedná jednoduše o příjmení uživatele, pak při přechodu není problém. Komplikace nastává v případě, kdy jsou na začátku uživatelského jména použity číslice. Jiná komplikace může nastat při samotném logování, protože zatímco prostředí Windows ignoruje velká a malá písmena (cosi = COSI). Navíc bude uživatelské jméno zobrazeno tak, jak bylo napsáno při vytvoření. Naopak v Unixu a OSS je citlivost na velká a malá písmena podstatná. Uživatel musí při loginu napsat své uživatelské jméno přesně tak, jako když bylo vytvořeno. V dnešní době systémy umožňují používat dlouhá uživatelská jména s různými znaky. Systémy autentifikace a autorizace dnes používají systém LDAP. Pozornost by měla být věnována případům, pokud by z nějakého důvodu bylo nutné implementovat starší verze software. V každém případě je dobrou praxí nepoužívat v uživatelském jménu mezery a omezit jeho délku tak, aby bylo možné se přihlašovat prostřednictvím emailu. Autentizační služby Jakákoliv síť potřebuje daleko víc než kterýkoliv počítač autentizační služby a pojmenovaní v rámci sítě. Ve Windows NT existoval tzv. Domain Controller, později Active Direct. Často je instalován Novell NDS aj. Většina Unix a OSS systémů může pracovat s téměř všemi autentifikačními službami. Právě Linux je v této oblasti velmi silný. Přestože je níže uvedeno řešení LDAP, je samozřejmě použít několikanásobné přejmenování atp. Soubory Velmi podstatnou částí přechodu je plán migrace dat ze starého do nového systému. Pokud je připraveno na přechod v jednom okamžiku (což je nepravděpodobné), pak není třeba provozovat paralelní cross-platformový přístup k souborům. Významná pozornost datům je nutná při přechodu, aby nedošlo ke ztrátě dat. Častým důvodem může být zmatení z důvodu existence kopií v novém i starém systému. Obsah a formát

59

Tradičně diskutované téma je rozebíráno níže. Standardní přístup je používat OSS aplikace, které mohou číst soubory vytvořené v proprietární aplikaci. Je vhodné zvážit tzv. hromadnou konverzi formátu jako součást přechodu prostřednictvím speciálních skriptů. Názvy souborů Názvy souborů ve Windows nejsou citlivé na rozdíly mezi velkými a malými písmeny. Některé aplikace mohou stále používat DOSovskou konvenci. Zpětné lomítko „\“ je používáno jako oddělovač adresářů. Běžné jsou mezery v názvu. Řada uživatelů si neuvědomuje, že absolutní názvy souborů musí obsahovat písmeno jednotky, na které se fyzicky soubor nalézá, nebo název serveru v případě síťové jednotky. Tato restrikce může představovat problém v případě u větších systémů. Jiné proprietární systémy přistupují k souborovým názvům různě. VMS například rozlišuje veliká a malá písmenka v názvu a po dvojtečce očekává číslo verze atp. Souborové názvy v Unixu a OSS systémech mají různá pravidla. Názvy zohledňují velká a malá písmenka. Přestože ve většině Evropy se používá znaková sada ISO .. a jediným znakem, který nemůže být v Linuxu použit v názvu souboru je lomítko „/“ (oddělovač adresářů) není praktické používat znaky, které Windows FAT32 neumí ukládat (prvních32 znaků ASCII kódu nebo interpunkční znaménka, grafické značky atp. Také mezery jsou nepraktické, protože si jich nemusí uživatel v příkazové řádce všimnout. Unix a OSS systémy nepoužívají písmena k označení jednotky ani názvy serveru jako součást absolutního názvu souboru. Místo toho systém prezentuje soubory jako součást jedné hierarchie. Používání symbolických propojení mezi souborovým systémem a daty ovládanými automatickými montéry, dává systémovým administrátorům svobodu a flexibilitu v oddělování absolutních jmen souborů od svého fyzického umístění. Téměř všechny názvu souborů ve Windows mohou být přesunuty na OSS servery okamžitě beze změny. Jedinou výjimkou, která může nastat je používání lomítka „/“ v názvu. Toto lomítko by mělo být změněno během přesunu. Většina uživatelů grafického rozhraní pravděpodobně nikdy nezjistí, že název souboru je citlivý na velká a malá písmena, protože tento název píšou pouze jednou a to je při vytvoření souboru, pak už pracují pouze s grafickým zobrazením . Duální přístup Spousta migračních plánů zahrnuje období paralelního provozu, kdy někteří lidé používají OSS systémy a jiní stále pracují s proprietárními. Aby bylo možné přistupovat k datům z obou systémů, je nutné, aby byly vytvořeny zvláštní podmínky.

60

Sdílení souborů ve Windows používá tzv. Server Message Block protokol, který je velmi komplexní technologií s několikaúrovňovou zpětnou kompatibilitou. Je používána s dedikovanými souborovými servery a „peer-to-peer“ módem, kdy jednotlivé počítače dávají k dispozici některou část jejich souborového systému. Dobře řízené administrátorské prostředí je postavené na systematickém sdílení prostřednictvím dedikovaných serverů. Nesdílené uživatelské soubory v prostředí Windows mohou být drženy na několika místech: Na lokálním disku (např. C:); v konkrétním uživatelském profilu (Dokumenty); v „home directory“ na centrálně řízeném souborovém serveru, což je nejčastější řešení pro větší množství desktopů, pokud mají být jejich zálohy dělány systematicky. Není možné nabízet duální přístup souborům, které jsou uloženy na individuálních desktopech nebo noteboocích, proto veškeré lokálně uložená data by měla být přenesena na centrální servery na počátku migračního procesu. Jednodušší protokol s dobrou specifikací je Network File System (NFS), který je hlavním mechanizmem pro přístup k souborům na Unixu a OSS. Možnosti pro implementaci duálního přístupu spadají do dvou kategorií. Přidání podpory duálního protokolu na servery nebo přidání duální podpory na klienty. Další části jsou stejné a obvykle je snazší změnit servery než klienty, a téměř vždy je snazší upravit OSS systémy než ty proprietární. Možnosti ukazuje následující tabulka.

Windows klienti

Windows servery

OSS nebo Unix servery

SMB souborový přístup

Servery

podporují

SMB

používáním Samba OSS klienti

OSS klienti mohou přistupovat NFS

souborový

k SMB sdílení. Komerční Unix standardem.

přístup

OSS

je

klienti

obvykle nemají možnosti SMB mohou používat SMB, pokud je klienta. Přidání NFS služby na to Windows

záměrem

a

součástí

servery může být migračního plánu, nicméně je

finančně nákladné.

to méně efektivní.

61

Nástroje Tato sekce popisuje některé z klíčových OSS komponent, které budou použity v případě migrace z proprietárních systémů. •

Samba

Samba je souborový a tiskový serverový balík pro OSS systémy. Zahrnuje SMB protokol a v mnoha případech úplně nahrazuje funkce Windows serveru. Nástroj Samba se může také chovat jako Windows NT Domain Controller a je schopen skladovat domain management data v adresářích přístupných pomocí LDAP. Samba také nabízí SMB klientské nástroje, které jsou vhodné pro skriptování a které jsou velmi užitečné při diagnostice problémů se SMB sítěmi, a také dělají hromadné souborové přenosy z Windows serverů. Projekt Samba má kvalitní vývojovou podporu v rámci komunity po celém světě. •

OpenLDAP

OpenLDAP je implementací Lightweight Directory Access Protocol (LDAP), která zahrnuje adresářový server, sadu nástrojů pro management a přístup k datům a sadu knihoven pro podporu LDAP v dalších aplikacích. •

NSS a PAM

Name Service Switch je technologie používaná Linuxem ke komerčním Unix variantám, které opravňují různé služby, aby byly používány v případech vyhledávání hostnames, uživatelských jmen, jmen pracovních skupin atp. Z řady dostupných modulů jsou pro projekt zajímavé např.: soubory: Jednoduché vyhledávání založené na lokálních textových souborech o

DNS: vyhledávání hostname založené na DNS

o

LDAP: vyhledávání založené na LDAP

o

SMB: vyhledávání využívající SMB protokol

Pluggage Authentication Module (PAM) je systém dostupný jak v Linuxu tak FreeBSD, který poskytuje velkou flexibilitu při konfiguraci autentizačních a autorizačních procesů. Relevantní moduly zahrnují: o

LDAP: používá LDAP k provázání operací s cílem ověřit uživatele

o

SMB: používá Windows domain operace k ověření uživatele

o

Accesss: omezuje přístup k síťovým službám

o

Cracklib: vynucuje kontrolu kvality nových hesel

62

•

Linux SMBFS souborový přístup

Samba umožňuje OSS systému, aby poskytoval souborové služby Windows klientům. SMBFS pracuje jinak než Samba. SMBFS je součástí většiny distribucí a umožňuje přístup k souborům uloženým na Windows serverech. Model kontroly přístupu používaný souborovým systémem ve Windows je totiž odlišný od toho, který je používán Linuxem a dalšími OSS systémy. Tato omezení mohou být překonána za pomocí SMBFD. •

Windbind

Jiným produktem v rámci projektu Samba je produkt Windbind, který individuálním počítačům pod Linuxem umožňuje, aby byli dostupné pro Windows NT domény. Produkt udržuje mapování mezi Windows autentifikátory SID a Unixovým UID a GID. Windbind umí řadu dalších věcí, které redukují zátěž systému administrátorů, jako např. nastavení jakoby Unixového prostředí pro lidi, kteří se poprvé pokoušejí přihlásit. Nevýhodou produktu Windbind je budování rozsáhlé sítě, kterou každý klientský počítač vytváří tím, že mapuje mezi Windows a Unix autentifikátory. Tato nevýhoda může působit problémy v pokročilejší fázi migrace, kdy se začnou používat OSS souborové servery. Windbind formuje uživatelská jména a skupiny Linuxu pro použití v Windows NT domain prostřednictvím unikátního stringu.

To může vést ke zmatení, protože většina běžných Unixových

utilit poskytuje

prostor pro jejich výstupy pouze v rámci osmimístných názvů. Delší názvy jsou tak ve Windbind oříznuty.

6.1.4. Migrace prostředí operačního systému Individuální Linux servery k existujícím Windows NT doménám •

Nastavení je velmi snadné:

•

Nainstalovat GNU/Linux server a přidělení pevné IP adresy .

•

Ujistit se, že Samba balíčky jsou nainstalovány. Samba, samba-common a samba-client jsou požadovány a obvykle jsou zahrnuty v „serverové“ instalaci.

•

Editovat /etc/samba/smb.conf, nastavit domain security mode a definovat název domény (pracovní skupiny). Vypsat PDC a BDC jako heslové servery. Definovat sdílení, které má být zajištěno daným počítačem.

•

Vytvořit adresáře, které mají být sdíleny a nastavení odpovídajících vlastnických a přístupových práv.

•

Připojení počítače k existující Windows NT doméně za pomocí Domain Admin hesla (nebo jiného uživatelského jména a hesla, které má sílu to udělat)

63

o •

smbpasswd -j DOMAINNAME -r PDCNAME -U Administrator

Spustit Samba a nastavit restart a reboot: o

/etc/init.d/smb start

o

chkconfig smb on

Nyní se server ukáže ve výpisu a může být používán stejně jako Windows NT server. Spuštění pracovní stanice pod Linuxem v Windows NT doméně Jednoduchý postup pro nastavení malého počtu počítačů V raných stádiích testování OSS nástrojů je velmi užitečné používat individuální Linux počítače se základní konfigurací. Tyto počítače pak mohou být oprávněny přistupovat k souborům na Windows serverech a být využity jako testovací počítače pro ověření kompatibility během přípravy migrace. Připojení disku „mounting“ je Unix/OSS termín pro zapojení disku nebo vzdáleného souborového systému do lokální souborové hierarchie počítače. Tento proces je prováděn automaticky při bootovací proceduře podle souboru /etc/fstab, ale může být prováděn interaktivně při připojení jednotky. Manuální zapojení např. CD-ROM jednotky by probíhalo pomocí: mount /dev/cdrom /mnt/cdrom Příkaz mount je obvykle zakázán administrátorem z bezpečnostních důvodů. Není to problém, pokud je počítač užíván systémovým administrátorem, ale může být problematický v případě uživatele laika. Linux tento problém řeší několika způsoby. Zvláštním zápisem v souboru /etc/fstab je možné umožnit obyčejným uživatelům připojovat předdefinované objekty (CDROM, diskety, USB paměťová média atp.). Program setuid-root dělá privilegované operace, kdykoliv zjistí, že to je bezpečné. Toto je způsob jak např. připojovat vzdálené sdílené Windows disky. Jinou možností je použít automounter, který připojí souborový systém kdykoliv je k němu poprvé přistoupeno. Zároveň systém odpojí, pokud není delší dobu používán. Automounter běží na pozadí jako daemon. Nakonfigurovat tohoto daemona může být časově náročnější, ale je to velmi efektivní způsob řízení v organizacích s velkým počtem stanic. V tomto

64

schématu použijeme smbmount a smbumount příkazy, které umožňují, aby sdílené složky Windows vypadaly jako součást Linuxu. V řadě distribucí jsou tyto systémy součástí balíčku samba-client, který by měl být nainstalován spolu se samba-common. Tyto programy jsou navrženy tak, že kritické části byly pod kontrolou roota. Někdy je nutné, aby instalace byla před prvním použitím upravena pomocí příkazů: chmod u+s /usr/bin/smbmnt /usr/bin/smbumount Je nutné vzít v potaz, že změny se dějí smbmnt spíše než smbmount. Je to důležité, protože smbmnt zahrnuje pouze ty funkce smbmount, které vyžadují práva roota. S touto úpravou může jakýkoliv uživatel používat smbmount a smbumount aniž by potřeboval práva roota. Nyní může jakýkoliv uživatel vytvořit Windows SMB sdílení, které je přístupné prostřednictvím souborového systému v Linuxu přes mounting daného adresáře. Je možné popsat modelovou situaci: Uživatel Linuxu se chce připojit na NT server nazvaný NT5 v doméně SPOLECNE, která je sdílená pod jménem UZIVATELX a je vlastněna uživatelem se jménem UZIVATELX. mkdir ~/ntfiles

(“~/” znamená “v mém adresáři”)

smbmount //nt5/uzivatelx ~/ntfiles \

(připojení vzdáleného sdílení, „\“ znamená

pokračování ) -o username=uzivatelz -o workgroup=spolecne (toto je pokračování předchozí řádky) Po vyzvání se zadá heslo uživatele „uzivatelx“. Pro usnadnění je možné připravit skript, který by spouštěl tuto proceduru. Soubory na vzdáleném disku se nyní mohou vytvářet, editovat nebo mazat, ale není možné měnit jejich mód nebo vlastnictví. Před odlogováním je vhodné „odmountovat“ sdílení: smbumount ~/ntfiles Důležité je, že smbmount nevytváří permanentní spojení mezi účty v Linuxu a existujícím účtem ve Windows serveru, takže uživatelská jména a hesla mohou být udržována separátně na každém počítači. Úsilí managementu vynaložené tímto způsobem by na větší počet počítačů bylo velmi neefektivní, proto toto řešení je vhodné pouze pro účely testování. Nastavení pro větší skupiny

65

Jakmile dochází k pilotnímu testování většího množství pracovních stanic, stále může být aktuální případ, že data a autentizační jsou držena na Windows NT serverech. I v tomto případě Windbind projektu Samba poskytuje snadné řešení pro propojení těchto prostředí. Samba a Winbind jsou standardní součástí např. distribuce Red Hat, ale nemusí být defaultně nainstalovány na pracovních stanicích. Aby mohl být Windbind používán, je nutné mít nainstalováno samba, samba-common, samba-client. Soubor /etc/samba/smb.conf musí být editován tak, aby zobrazoval správné doménové jméno Windows NT v pracovní skupině a dal systém do domain security mode. Windbind konfigurační data mohou vypadat následovně: # oddělit domain a username s '+', jako DOMAIN+username winbind separator = + # použít uids od 10000 do 20000 pro domain users winbind uid = 10000-20000 # použít gids od 10000 do 20000 pro domain groups winbind gid = 10000-20000 # umožnit enumeraci winbind users a groups winbind enum users = yes winbind enum groups = yes # přidělit winbind users domovský adresář template homedir = /home/winnt/%D/%U # a shell template shell = /bin/bash Aby mohl Winbind fungovat je zapotřebí spustit některé procesy, které se spouštějí: chkconfig smb on chkconfig winbind on /etc/init.d/smb start /etc/init.d/winbind start Nyní musí být zadáno jméno a heslo s odpovídajícími právy (administrátora) smbpasswd -j DOMAINNAME -r PDCNAME -U Administrator Nyní se vypíše seznam uživatelů a pracovních skupin ve Windows.

66

wbinfo -u wbinfo -g Aby byly Windbind data dostupné pro systém je nutné editovat konfigurační soubory PAM a NSS. Tyto změny musí být dělány velmi obezřetně, protože se uživatel již nemusí dostat do systému, pokud jsou tyto soubory poškozeny. V souboru /etc/nsswitch.conf je nutné přidat slovo winbind k řádkům passwd (heslo) a group (skupina). V souboru /etc/pam.d/system-auth je nutné přidat řádek: auth sufficient /lib/security/pam_winbind.so use_first_pass hned za ekvivalentem řádku auth, se použije pam_unix, a následující řádek password sufficient /lib/security/pam_winbind.so use_first_pass hned za ekvivalentem řádku password, se použije pam_unix. Nyní bude nutné restartovat Name Service Cache Daemon v tomto okamžiku: /etc/init.d/nscd restart Překlad usernames a groups ve Windows do formátu passwd Unixu je možné dosáhnout: getent passwd getent group Aby se docílilo vytváření „home directories“ domácích adresářů při prvním loginu je vhodné přidat do session část /etc/pam.d/system-auth session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022 Toto vytvoří separátní domácí adresář pro uživatele na každé pracovní stanici, kterou používá. Užitečné je umístit skript do /etc/skel adresáře, aby každý uživatel automaticky mountoval své vlastní Windows NT soubory v standardním místě a čase.

67

Spouštění pracovních stanic Linux v Active Directory doménách Ve zkratce je možné poznamenat, že domény Active Directory (AD) je možné připojit stejně jako NT domény. Ve skutečnosti AD domény běží v módu kompatibility, takže může být použit naprosto stejný proces. AD domény také nabízejí možnost použití LDAP pro autentizace a vyhledávání dat. Jedná se o stejné schéma, které je použito pro větší sítě na čistě OSS systémech. Rozšířením AD schématu tak, aby obsahovalo Unixová data, je možné docílit toho, aby byli uživatelé OSS pracovních stanic a servery řízeni administrátorskými nástroji AD. Ukládání dat centrálně je vhodnější v případě, že je Windbind používán spolu s Windows NT, protože to udržuje konzistentní mapování mezi Windows NT IDs a Unix IDs na všech počítačích. Nahrazení Windows NT PDC/BDC Sambou a LDAP Samba může plnit roli Primary Domain Controlleru (PDC), a tak umožnit všem Windows serverům, aby byly eliminovány a to i v případě, že někteří Windows klienti jsou stále zapotřebí. Je vhodné si uvědomit, že není možné nahradit pouze PDC nebo BDC v doméně, protože všechny doménové kontroléry musí provozovat stejný systém – buď Windows nebo Samba. Je to částečně kvůli PDC-BCD replikačními protokolu, který nebyl vyvinut reverzním inženýrstvím. Samba doménové kontroléry také směřují na LDAP servery, kde jsou data aktuálně uložena. Nastavení Samba a LDAP je rozsáhlý proces, který může vzít zkušené osobě i celý den práce. Důležitým úkolem v rámci migrace je přenesení uživatelských jmen a názvy skupin ze současné domény. Některá práce může být udělána pomocí Samba-LDAP-HOWTO z IDEALX. Proces se sestává z několika milníků: Nainstalovat OSS server se Sambou a OpenLDAP. Přidat definici schématu Samba na LDAP server. •

Nastavit LDAP server s vhodným Distinguished Name (DN) a stromovou strukturou adresářů (za pomocí nástrojů např. IDEALX).

•

Spustit Samba a zkontrolovat funkci Domain Controller

•

Použít pwdump na PDC, aby s vypsaly všechny uživatelské záznamy v SAM. Výsledek převést ve formě textového souboru na OSS server.

•

Konfigurovat nástroj IDEALX smbldap-migrate-accounts.pl, aby odpovídal prostředí , které je vytvářeno. Tato konfigurace není triviální, poněvadž existuje řada možností.

•

Spustit smbldap-migrate-aaccounts.pl pro data přenesená z PDC, což vytvoří zápisy v LDAP pro všechny doménové uživatele. Také to vytvoří jejich SMB hesla, která

68

budou odpovídat těm z Windows NT (Unix nebo Linuxoví uživatelé se však s těmito hesly nebudou moci přihlásit, protože hesla Windows NT jsou hashed a OSS systémy používají jiné hash schémata). Současně je možné vytvořit domácí adresáře pokud je to požadováno. •

Zkopírovat uživatelské soubory a přenesení profilů z Windows serverů na OSS servery nebo převázat stávající Windows servery na doménu nyní obsluhovanou pomocí doménových kontrolérů Samba.

Velké sítě často vyžadují multiple LDAP servery, které kvůli odolnosti data replikují. Pokud je jeden doménový kontrolér Samba spojen s každým LDAP serverem, pak může být realizováno schéma, které je velmi podobné nastavení Windows PDC/BDC. Musí být vzaty v potaz ještě některé otázky: Výběr nástrojů pro management uživatelů •

Jak Windows NT skupiny a ACL budou namapovány na Unixové skupin a ACL

•

Jestli použít nové doménové jméno pro OSS služby

•

Jak vytvořit hash hesla použitelný pro OSS systémy nebo jestli používat hash Windows NT nebo LANMAN

Nahrazení Windows 2000 a XP s LDAP Tyto systémy nepoužívají LDAP pro přístup ke všem datům a pro autentizaci používají variantu Kerberosu. Možností jak se vypořádat s tímto problémem je několik. V duchu tradičního řešení je možné spouštět klienty Windows 2000 a Windows XP v Windows NT doméně jak bylo popsáno výše. Klienti Windows Vista nebyli vzhledem k relativně malému rozšíření v podnicích v době vzniku tohoto materiálu řešeni. Provozování paralelní infrastruktury Linux a migrace uživatelů ve skupinách Nahrazení všech Windows klientů Linuxovými Toto je nejjednodušší z možných migračních schémat. V interakci mezi Windows a OSS systémy je limit jednoho transferu uživatelských souborů. Proces může v návrhu vypadat následovně: •

Vybudování jádra OSS prostředí., které zahrnuje LDAP servery, aby udržovaly konfiguraci a data uživatelského jména, master instalační servery, tiskové servery a dostatečné množství klientských pracovních stanic pro systémový management a administrátory.

69

•

Vytvořit vývojové a tréningové prostředí s dostatečným počtem pracovních stanic, které by umožňovaly zaškolení dostatečně velké skupiny lidí. Počátečním úkolem tohoto prostředí, je validace a odladění pracovních stanic před hlavní vlnou přechodu. Proces přebudování pracovních stanic by v této fázi měl být dokončen, takže počítače mohou být nastaveny s minimálním úsilím. Velmi důležité je, aby všechny pracovní stanice byly nainstalovány úplně stejně během hlavního přechodu, takže mohou být pečlivě otestovány.

•

Použití vývojových a tréningových prostředí pro konzultaci s hlavními zástupci uživatelské skupiny, aby bylo podníceno zaujetí pro projekt a sbírána zpětná vazba z uživatelského rozhraní. Změny by měly být zapracovány před hlavním přechodem.

•

Vybudování skupiny nových pracovních stanic, které mohou nahradit stávající stanice používané první skupinou, která je určená na přechod na OSS.

•

Registrovat první skupinu uživatelů nového systému.

•

Vyškolení nové skupiny uživatelů na novém systému.

•

Uvedení testovacího prostředí do výchozího stavu, pokud bylo během školení překonfigurováno za účelem prezentace.

•

Nahrazení první skupiny pracovních stanic počítači s nastaveným OSS systémem a překopírování souborů první skupiny na nové souborové servery s tím, že původní soubory jsou nastaveny jako „pouze pro čtení“.

•

Poskytnutí aktivní podpory první skupině, zatímco si zvykají na práci s OSS systémem.

•

Upgrade počítačů, které byly odebrány první skupině a instalace standardního OSS prostředí dle plánu

•

Opakování procesu od kroku 5 pro další skupinu uživatelů.

•

Jakmile všichni uživatelé přešli na OSS systém je nutné provést zálohy dat všech starých serverů a přenesení jejich využití na nové.

Udržení některých Windows klientů Pro Windows klienty, které se ze zřejmých ekonomických důvodů nevyplatí přejít na OSS řešení, existují dvě možná řešení: Pro malou skupinu Windows klientů zachovat i jeden nebo nezbytné množství Windows serverů. Podporovat Windows klienty prostřednictvím OSS serverů a Samba. Samba 70

Cesta, kterou administrátoři zvolí, záleží na tom, proč musí být Windows klienti zachováni a také na jejich geografickém rozmístění. V každém případě je velmi pravděpodobné, že Samba bude používána na nejméně jednom z nových serverů, kde bude poskytovat sdílení souborů mezi Windows a OSS klienty.

6.1.5. Migrace aplikací na straně serveru Webové servery: přesun z IIS na Apache Obvyklý Windows web server Internet Information Server (IIS ), který poskytuje http, FTP a Gopher služby v jednom balíku. IIS řešení bylo po problémech se stabilitou a bezpečností opouštěno již před několika lety. Spousta OSS řešení má velmi liberální podmínky a nahradily IIS řešení. V případě přechodu z IIS na Apache s PHP nebo Perl moduly pro skriptování, existuje řada variant přechodu, protože Apache běží jak pod Linuxem nebo FreeBSD, tak pod Unixem nebo Windows. •

Poznámky k migraci

Názvy souborů a URL Pokud se přesouvá jednoduchá webová stránka z IIS pod Windows na Apache pod Linuxem, je nutné si uvědomit, že Windows souborový systém ignoruje velká a malá písmenka v názvech, avšak Linux a Unix to rozlišují. Z hlediska standardní webové hierarchie to znamená, že URL jsou citlivé na velikost písmenek, pokud jsou přesunuty do Linuxu. Tento případ však neplatí, pokud i na Windows serveru byl používán Apache. Méně obvyklou záležitostí je fakt, že IIS akceptuje obojí lomítka „/“ i “\“ jako oddělovače. Důsledek toho představuje problémy u webových stránek, které byly vytvářeny za pomocí Windows software, protože jejich struktura je nekonzistentní jak po stránce písmenek, tak po stránce lomítek, které jsou používány v případech, kdy webová struktura používá subadresáře. Přestože Apache se dovede s tímto problémem vypořádat, je dobré opravit tyto problémy v datech webové stránky.

6.1.6. Image maps na straně serveru Některé ze starších webových stránek používající mapování na straně serveru z x,y souřadnic v obrázku a odkazují na nějakou URL. Tento postup se dnes již příliš neužívá, protože znemožňuje přecházet na odkazovanou stránku v prohlížečích bez grafického rozhraní, čímž provozovatel stránky diskriminuje tělesně postižené. Mapy na straně serveru v IIS berou formát souborů s koncovkou .map, ale tento formát není použitelný pro Apache. Nejvhodnějším řešením je konvertovat mapy na straně serveru na mapy na straně klienta, protože s tím jsou také lepší zkušenosti po stránce prohlížečů. Pokud toto řešení není možné, pak jednoduchý Perl skript může být použit pro editaci souborů do formy použitelné 71

pro Apache. Skripty a databázová spojení Komplexnější stránky mohou mít dnes již standardně zabudované „redakční“ dynamické rozhraní založené na skriptování a přístupu do databáze. Většina ISS stránek používající Active Server Pages (ASP) jako skriptovací framework a může používat MS Access nebo SQL Server jako databázi v závislosti na velikosti aplikace. Existuje mnoho způsobů jak se vypořádat s převodem ASP skriptů. Nejčastěji používané jsou následující: •

Chili!Soft ASP balíček pro Unix (Sun ONE Active Server Pages) – proprietární , ale nenákladné řešení

•

ASP2PHP

•

Apache's Apache::ASO modul

•

Manuální konverze do nového jazyka

ASP2PHP je skriptovací konverter, který je schopen převést textové soubory napsané v ASP a VBScript do textových souborů napsaných v PHP. U větších projektů není možné se vyhnout manuálním úpravám, protože ASP2PHP upravuje některé syntaxe. Převedení některých stránek nemá smysl, pak je vhodnější uvažovat o použití projektů jako např. Template Toolkit. Apache::ASP poskytuje ASP vlastnosti přímo z prostředí Apache, avšak VBScript a Jscript nejsou podporovány. Všechny Apache skriptovací systémy jsou schopny přistupovat k databázím typu (SQL, flat file, indexed, LDAP, NIS atd.). Rozšíření FrontPage FrontPage je balíček pro návrh webových stránek, který uvedl několik rozšíření, která mohou umožňovat vzdálenou správu obsahu webu a která byla dříve používána jinými web-design balíčky. FrontPage rozšíření jsou dostupná pro Unix systémy, ale nejsou příliš populární mezi Apache administrátory kvůli bezpečnostním otázkám a mnoha nutným změnám, které musí být udělány na straně uložení webové stránky. Od verze Office 2000 je možné použít alternativní řešení, které používá WebDAV protokol. Linux/Apache server tak může obsluhovat jak OSS, tak i proprietární klienty používající mechanizmy Windows Exploreru.

72

73

•

Migrace statické webové stránky

Tento příklad ukazuje kompletní proces migrace jednoduché statické stránky z IIS na Windows NT na Linux/Apache řešení. 1. Připravit Linux server, připojit jej k síti a otestovat Apache, který je součástí většiny distribucí již předkonfigurovaný. 2. Zkopírování webové stránky na ISS serveru (obvykle v C:\InetPub) a komprimace. 3. Vložení webové stránky na vybrané místo na novém serveru. Místo by mělo být v souboru httpd.conf v /var/www/html nakonfigurováno jako DocumentRoot. 4. Editovat httpd.conf a přidat default.htm do DirectoryIndex clause. (Zatímco Apache vyhledává index.html, IIS používá default.htm – tato akce umožní používání obojího bez nutnosti měnit kód stránky a přejmenovávat výchozí soubor webové stránky.) 5. Stránka by měla v této fázi fungovat, a tak by měla být adresována jménem nového serveru spíše než přesným URL. To může být problém v případě, kdy stránka používá nekonzistentní velká a malá písmena nebo zpětná lomítka v názvech souborů. 6. Testování stránky a oprava chyb ve zdrojovém kódu. Pro efektivní práci je vhodné použít některý z automatizovaných nástrojů pro kontrolu kódu a také prověřit funkcionalitu odkazů. 7. Pokud úprava dat není proveditelná je možné spustit modul, který provede scan adresářů a přesměruje http v případě chybné URL, přidáním následujících řádků do http.conf: LoadModule speling_module modules/mod_speling.so AddModule mod_speling.c CheckSpelling

on

8. Stránky, které používají zpětné lomítko „\“ v URL mohou být opraveny prostřednictvím mod_rewrite a přidáním následujících řádků do httpd.conf RewriteEngine on RewriteRule ^(.*)\\(.*)$ $1/$2 [N] 9. Zkontrolovat obrázkové mapy použité na straně serveru použitím příkazu: find /var/www/html -name '*.map' –print

74

10. V případě, že map je více je vhodné použít skript. 11. Stránka by měla být opravena a nyní je možné nastavit Samba nebo WebDAV, aby bylo možné ke stránce přistupovat za účelem aktualizace i z proprietárních produktů. 12. Posledním krokem by mělo být přesměrování DNS záznamů na nový server nebo změna IP adresy na novém serveru a zrušení starého serveru poté, co byla provedena kompletní archivace dat. Jednoduchá konfigurace WebDAV WebDAV může být používán k řízení obsahu některé nebo všech stránek, které organizace používá. V tomto případě bude použit pro celou stránku, takže žádný jiný přístup není nutný a povolený. Jiné systémy pro správu obsahu jako např. FTP nebo direct file access používají jiné klíčovací schéma. 1. Vytvořit adresář pro WebDAV zámky, které budou vlastněny stejnou skupinou a uživatelem, který provozuje Apache (viz. User a Group konfigurace v httpd.conf). Dobrou volbou jsou /var/httpd/webdvlocks. 2. Přidat následující řádky do hlavní části httpd.conf Loadmodule dav_module libexec/libdav.so Addmodule mod_dav.c DAVLockDB /var/httpd/webdavlocks 3. Naleznout Adresář nebo umístění, které jsou asociovány s defaultní webovou stránkou a přidat následující řádky:

DAV On AllowOverride None Options Indexes AuthType Basic AuthName "Pouze pro administrátory" AuthUserFile /var/httpd/htpasswd require valid-user

75

4. Ujistit se, že asociované soubory a adresáře jsou vlastněné pouze stejným uživatelem a uživatelskou skupinou, která provozuje Apache, pomocí: chown

-R

apache:apache

/var/www/html

5. Vytvořit soubor s heslem: touch /var/httpd/htpasswd chown root:apache /var/httpd/htpasswd chmod 640 /var/httpd/htpasswd 6. Vytvořit heslo pro uživatele „webadmin“ htpasswd -m /var/httpd/htpasswd webadmin 7. Restartovat Apache nebo ho nechat znova načíst upravené konfigurační soubory: /etc/init.d/httpd reload 8. Nyní je možné převzít kontrolu nad webem prostřednictvím WebDAV protokolu. Ve Windows 2000 a pozdějších je možné přistupovat ke stránce z Windows Exploreru přes „Místa v síti“ nebo přes MS Office aplikace, které mohou ukládat data přímo na stránku. Linux poskytuje podobné funkce prostřednictvím davfs. 9. Důležité upozornění! Výše uvedené schéma poskytuje jen velmi omezenou bezpečnost. Aby mohlo být připojení bezpečnější je třeba zvolit vhodnou autentizační metodu, kterou Apache poskytuje. Také je možné použít SSL pro bezpečné transakce, které mohou být prováděny s pomocí Apache mod_ssl. Databáze – přesun z MS Accessu a SQL Serveru na MySQL nebo PostgreSQL Většina malých databázových projektů ve Windows používá Access. Tento produkt je hojně využíván nejen jednotlivými uživateli, protože je relativně snadný k ovládání, ale i jako vývojové prostředí pro menší projekty. Access není dimenzován pro větší projekty s propojením většího množství uživatelů, a také si neporadí s většími databázemi. Větší databáze jsou řešeny prostřednictvím SQL Serveru nebo jiné ze známých relačních databází jako jsou Oracle, Sysbase, DB2 aj. V případě, že organizace využívá tyto zmíněné databáze, pak je doporučováno ponechat servery v současném stavu a migrovat pouze klientské aplikace. Také většina kvalitních proprietárních jsou k dispozici pod platformami Linux nebo

76

Unix, takže je možné přejít na OSS platformu bez nutnosti měnit databázi. Nicméně je vhodné podotknout, že proprietární databáze nejsou levnou záležitostí, takže stojí za zvážení, zda by některý z OSS produktů nepostačoval pro splnění požadavků organizace. Mezi nejznámější OSS databáze patří MySQL a PostgreSQL. Oba produkty jsou vyspělé s aktivní vývojovou základnou, dobrou podporou standardního SQL a poskytují velmi kvalitní služby. Také se hodí vědět, že všechny databáze nemusí být relační. Některé úkoly se hodí řešit s jinými modely a přímým použitím takových OSS produktů jako je např. Berkeley DB, která může být extrémně efektivní. Podobně LDAP model hierarchické síťové databáze je vhodný pro některé typy distribuovaných aplikací. •

Migrace z databáze Access

Access je k dipozici pouze na platformě Windows, a tak pokud je plánováno výhradně OSS prostředí v organizaci, pak musí být podobná řešení nahrazena. Jedním z proveditelných scénářů migrace je přenesení dat z Access do OSS databáze, zatímco Access je používán jako front-end, čímž odpadá řada problémů s ukládáním dat v Accessu. •

Ruční export/import

Existuje několik způsobů jak migrovat data z Accessu do jiných databází. Pro jednoduché sady dat je nejvhodnější způsob exportovat je jako tabulky z Accessu v CSV formátu a pak naimportovat data na nový server. Tato metoda vyžaduje, aby byly vytvořené stejné tabulky na novém serveru, ale nevyžaduje speciální software. Příklad vytvoření jednoduché tabulky a import CSV do MySQL. mysql --user=myusername -p Pak zadat následující: create database mydb; use mydb; create table mytable ( firstname

char(30),

surname

char(30),

postcode

char(10)

); load data local infile 'exportfile.csv' into table mytable 77

fields terminated by ',' enclosed by '"' lines terminated by '\r\n'; •

Skriptovaný export/import

Některé skripty a programy jsou schopné exportovat databázi Access kompletně, včetně informací nezbytných pro vytvoření tabulky v nové databázi. Některé vytvářejí soubory, které mají být kopírovány na novou platformu, zatímco jiné se připojují přes síť přímo a dělají změny okamžitě. Příklad zapisujících skriptů lze nalézt v souboru exportsql2.txt na www.cynergi.net/exxportsql, který replikuje databázi Access do MySQL. Jiné postupy jsou popsány v materiálu „Migrating from Microsoft Access to MySQL“ na www.kitebird.com. •

Migrace SQL Server databází

Proces migrace je v mnohém podobný tomu, který je popsán výše. Pro menší datové celky je vždy možné exportovat databázi do CSV a znova ji naimportovat do nové databáze. Pro migraci existují OSS i komerční řešení. PGAdmin je free software pro administraci PostgreSQL databází. Existují plug in utility, které obsluhují migraci dat z jiných databázových strojů. SQLPorter je komerční produkt firmy Realsoft studio podobně jako SQLWays firmy Ispirer nebo SQLyog. Také na stránkách MySQL je možné nalézt spoustu nástrojů ke konverzi dat. Problémy s migrací databází Migrace dat je občas nejjednodušší části procesu. Problémy obvykle tvoří okolí databáze – skriptové prostředí atp. SQL sám o sobě je standardizovaný, ačkoliv většina firem podporuje organizace v užívání různých nestandardních rozšíření. Nástroje pro tvorbu formulářů a různé generátory aplikací obvykle nebudou fungovat s jinou databází než s tou, se kterou jsou prodávány (pro kterou byly vytvořeny). •

Groupware

Standardní program we Windows, který se stará o mail a základní groupware funkce je Exchange a Outlook. Všechny funkce Exchange mohou být nahrazeny OSS řešením. Alternativou pro Outlook je Evolution nebo Thunderbird včetně kalendáře lightning. •

Obecné problémy

Všichni uživatelé Exchange budou mít uloženo uživatelské jméno a heslo v systému.

78

Současné verze Exchange používají Active Directory, takže výše uvedené poznámky k migraci Active Directory se vztahují i na Exchange. Pro rekapitulaci je možné poznamenat, že OSS servery mohou přistupovat k datům prostřednictvím LDAP, takže nové servery mohou používat buď existující Active Directory nebo data mohou být jednoduše přenesena na OSS úložiště jako např. OpenLDAP. •

Problémy s emailem

Uživatelé mohou mít podstatnou část emailů sdílenou s ostatními uživateli ve skupině. Moho u mít další procedurální nebo právní požadavky na to, aby bylo evidováno jaké emaily byly přijaty a odeslány. V takových případech musí být zvážen způsob uložení a přístup k datům. Lidé užívající přenosné počítače mohou ukládat emaily na svůj laptop nebo používat synchronizovanou kopii původního souboru na centrálním úložišti. Pokud se plánuje migrace na OSS mailové služby, pak je důležité lokalizovat všechna uložená data a zajistit jejich dostupnost i do budoucna z OSS prostředí. Exchange může používat Windows groups jako distribuční seznamy, což jsou tytéž skupiny, které ve Windows používá pro kontrolu přístupu. Takové řešení správy distribučního seznamu je v OSS obvyklé, ale může být nastaveno. Pokud by byl Outlook udržován jako používaný emailový klient, tak musí být překonfigurován, aby používal IMAP spíše než nativní přístup k mailboxům. Exchange nemá žádné rozhraní pro export, takže migrace dat musí být provedena přes připojení klienta. •

Problémy s Adresářem

Uživatelé Outlook u používají automaticky vestavěný adresář. Mohou také přistupovat ke sdíleným adresářům v případě, že je používán Exchange server. Obsah těchto adresářů musí být přenesen ve formě, která je čitelná pro OSS ekvivalenty. Osobní adresáře mohou být exportovány v vCard formátu, který je podporován spoustou mailových klientů a může být parsován skripty pro konverzi do jiných formátů, pokud je to zapotřebí. Podobně sdílené adresáře mohou být exportovány, a následně nahrávány do LDAP úložiště. Hlavním problémem je, že jak Outlook, tak i Exchange nepoužívají standard RFC822 pro mailové adresy, takže data z adresáře nebudou obsahovat použitelné adresy v případě exportu. V tomto případě je nutné použít skript s přístupem do Active Directory úložiště a přeložit interní formát adres do formátu adres RFC822. Tento překlad se bude velmi pravděpodobně potřebovat např. v případě, kdy Outlook bude používán jako mailový klient, protože nebude moci používat interní formát adres pokud budou emaily posílány přes protokoly jako SMTP.

79

•

Problémy s kalendářem

Kalendáře mohou být exportovány do formátu vCal, a poté přesunuty na nový server nebo manažerkou platformu.

6.1.7. Migrace pracovní stanice na OSS Kancelář Konverze dokumentů OpenOffice je schopný číst a zapisovat ve formátu .doc velmi dobře, takže není nutné převádět dokumenty do nového formátu během migrace. Pokud je vyžadována konverze, pak tento proces může být prováděn prostřednictvím funkce Autopilota v z rozbalovacího menu Soubor v OpenOffice. Volba masové konverze záleží na zamýšleném využití dokumentu v budoucnosti. V případě, že bude dokument reeditován, pak je rozhodující formát používaný většinou editorů. Konverze šablon OpenOffice umí přímo používat šablony MS Wordu a vyšší, avšak v praxi je vhodnější překonvertovat šablony do nativního formátu a uložit je na sdílené úložiště. Funkce Autopilota může být použita pro masovou konverzi, avšak je vhodné následně manuálně šablony otestovat a případně doopravit. Šablony jiných textových procesorů musí být upravovány ručně. Konverze maker OpenOffice používá BASIC jako hlavní makro jazyk. Strukturou je velmi podobný jazyku, který je používán Wordem a pozdějších verzí Wordperfect, nicméně jména objektů jsou jiná, takže všechna makra musí být manuálně přepsána. Makra v dokumentech obsahují bezpečnostní rizika a často nejsou nutná pro každodenní využití. Většina formátovacích procedur může byt nahrazena pomocí stylování a o jednoduchou manipulaci s daty se mohou postarat formuláře. OpenOffice samozřejmě obsahuje tzv. Macro recorder, který umožňuje jednoduše vytvářet makra, pokud je to nutné. Automatická konverze maker však možná není. Textové procesory Pod platformou Windows existuje celá řada nástrojů pro zpracovávání textů. Většina organizací používá jednotné nástroje v celé organizaci. Rozšířené komerční produkty jsou: Microsoft Word Microsoft Works 80

WordPerfect Lotus AmiPro a Lotus WordPro Lotus Notes IBMDisplayWrite Některé z uvedených komerčních formátů vyžadují při konverzi „meziformát“. V současné době existuje řada webových stránek a projektů, které popisují OpenOffice jako jednoduchou alternativu, která nevyžaduje dlouhodobé zaškolování. Publishing Mezi nejrozšířenější publishingové (DTP) procesory patří: Framemaker, Pagemaker, QuarkXPress. OSS alternativou je Scribus, který velmi kvalitně supluje uvedené komerční produkty. Také OpenOffice není pouhou sadou kancelářského balíku, ale snaží se integrovat pokročilé funkce (např. Master Document), které umožňují spravovat větší tiskové projekty a layouty stránek, které mohou být velmi flexibilní a užitečné např. při tvorbě knih a publikací. Tzv. Post-processing balíčky mohou být použité v situacích, kdy se pracuje s rychle se měnícím obsahem, který je ad hoc připravován podle aktuálního požadavku. Tabulkové procesory Nejrozšířenějšími zástupci tabulkových procesorů ve Windows jsou: Microsoft Excel, Lotus 123 a jeho deriváty. V OSS světě vedle OpenOffice existuje např Gnumeric a jiné. Stejně jako u textových procesorů veškerá makra musí být manuálně přepsána. U některých funkcí mohou ve vzorcích nastat drobné odlišnosti v syntaxi, takže složité tabulkové dokumenty vyžadují kontrolu funkčnosti. Prezentační software V prostředí Windows jsou prezentace zpravidla vytvářeny prostřednictvím aplikace PowerPoint nebo Corel Draw. PowerPoint je však rozšířenější.

OpenOffice umí číst a

pracovat s formátem .ppt bez významnějších problémů. Problémy jsou identifikovány akorát při používání složitějších animací, které mohou být vytvářeny od verze Office 2003 a nezobrazují se korektně. Na .ppt se vztahují výše popsané možnosti hromadného převodu formátu, pokud by to bylo z nějakého hlediska žádoucí. Grafika a práce s obrázky Grafické balíčky je možné rozdělit do tří různých kategorií - presentační grafika, vektorová grafika, bitmapová grafika.

81

Vektorová grafika Nejrozšířenější je OpenOffice, který zahrnuje editor Draw. OSS balíčkem, který je schopný číst formáty Visio je Dia, který je možné používat rpo vytváření diagramů dokumentace. Alternativou pro KDE je Kivio. Sodipodi je nástroj pro Scalable Vector Graphic (SVG). Před migrací je vhodné prověřit, zda proprietární formáty je možné převést do OSS alternativ. Bitmapová grafika Tato kategorie zahrnuje jak jednoduché programy typu Paint, tak profesionální nástroje pro práci s grafikou typu Photoshop. Ve světě OSS existuje nepřeberné množství projektů, které se snaží suplovat určité proprietární programy. Za balíček, který ční vysoko nad ostatními lze považovat Gimp, protože je schopen číst téměř všechny známé bitmapové formáty včetně interního formátu Photoshopu. Gimp je také umí sám vytvářet, a tak se hodí i pro konverze formátů. Gimp poskytuje veškeré funkce, které by měl dobrý painbrush program mít. Umí pracovat s vrstvami, kanály a dalšími pokročilými nástroji, které umožňují vytvářet podklady pro tisk i web. Identifikované problémy zahrnují nedostatečnou kvalitu zpracování barev, což může být problémem, pokud je vyžadována předtisková příprava v nejvyšší kvalitě. Generování PDF souborů je samozřejmou součástí většiny OSS produktů a zvládá to také OpenOffice. PDF může být vytvářeno jako tisková služba, takže i uživatelé pod Windows mohu tento formát vytvářet bez nutnosti kupovat Adobe Acrobat. E-mail V současné době existuje spousta uživatelských rozhraní pro email, které jsou plně OSS. Hlavní problémy na straně klienta, kterým je třeba věnovat pozornost v případě lokálního uložení dat zahrnuje: výběr nového mailového klienta a odpovídajícího rozhraní, migrace uložených osobních emailů, migrace uložených adresářových záznamů. Bez ohledu na MUA, který bude používán, je nutné počítat s migrací uložených emailů a adresáře. Pokud jsou emaily uloženy na IPAP serveru, pak tato starost odpadá. V případě, že byly emaily uloženy lokálně, pak je nutné s nimi dál pracovat (konvertovat je). V MS Outlook jsou emaily standardně uloženy v .pst souboru, který se nachází v adresáři: C:\Dokumenty a nastavení\\Local Settings\Data aplikací\Microsoft\Outlook Přestože Outlook zahrnuje svůj vlastní exportní formát do CSV nebo Excelu, toto řešení není vhodné, protože export nezahrne přílohy emailů! Při volbě emailového klienta je vhodné se podívat, zda existují nástroje, které by data z proprietárního prostředí překonvertovala. Kalendáře a Groupware Kalendáře jsou vedle kontakt managementu a emailu klíčovou oblastí, která bývá

82

integrovaná do jednoho provázaného balíku označovaného jako např. Personal Information Manager (PIM). Některé integrované balíčky jako MS Outlook poskytují všechny tři služby v jednom, zatímco jiné produkty mohou být vyhraněnější – například ACT!, který je blízký řešení, které bývá označováno jako Customer Relationship Management (CRM). V oblasti provázání funkčnosti, která je srovnatelná s Outlookem a v některých vlastnostech tento produkt předčí jsou již zmíněné projekty Evolution nebo Thunderbird, který díky dostupným rozšířením může být velmi komplexním personálním managerem. Kalendář využívá open iCalendar standard a je možné jej sdílet díky WebDAV protokolu. Většina OSS kalendářů je schopna číst formát iCalendar (vCalendar), který definuje a ukládá data v některém formátu RFC2445,6 nebo 7. Téměř všichni emailoví klienti, kteří existovali, definovali svůj vlastní formát pro ukládání adres. Naštěstí většina proprietárních i OSS emailových aplikací v nedávné době implementovala standard iCard (vCard), který umožňuje vzájemnou výměnu a synchronizaci dat. Jinou možností jak nakládat s adresářem je prostřednictvím LDAP. Možnosti použití jsou široké a uplatnění je možné nalézt jako sdílené telefonní seznamy, nebo mailing listy mezi několika organizacemi, kdy osobní adresář by byl příliš malý pro tento účel. Prohlížení webu Uživatelé Windows standardně používají Internet Explorer, i když jeho podíl mezi prohlížeči i na platformě Windows trvale klesá. Mezi OSS prohlížeči je nejrozšířenější Firefox Mozilla, který má i výrazný podíl na trhu (cca 30% uživatelů v Česku). Migrace na tento produkt je velmi snadná, protože Mozillu je možné najít i pod Windows. Mozilla velmi dobře převádí veškeré bookmarky (záložky) a nastavení z IE a Netscape. V případě přechodu na OSS platformu je však nutné nejdříve všechny záložky exportovat do souboru ve formátu HTML. Pokud organizace využívá intranet, který splňuje W3C.org standardy, pak není problém s přechodem na jakýkoliv webový prohlížeč. Stránky, které jsou závislé na JavaScriptu vyžadují pečlivé testování napříč různými prohlížeči, aby byly přístupné pro většinové webové prohlížeče. Pokud stránky mají zakomponované ActiveX technologie, musí být přepracovány, protože OSS prohlížeče nepodporují ActiveX technologii, která má velké bezpečnostní mezery. Běžně rozšířené zásuvné moduly (plugins) jako Java, PDF, Flash, Real Player a jiné jsou velmi dobře podporován OSS technologiemi.

83

Osobní databáze Uživatelé, kteří pracují s daty, která jsou příliš velká pro použití v Excelu, se obvykle přiklánějí k MS Accessu. Tento balík umožňuje vytvářet a spravovat relační databázi prostřednictvím skriptů a formulářů. Migrace do OSS prostředí byla již popsána. Pro rekapitulaci je vhodné na tomto místě zdůraznit, že OSS řešení poskytuje uživatelům přistupovat k centrálně spravované databázi na serveru. Uživatelé si mohou sami databáze vytvářet například prostřednictvím webového rozhraní – např. PHPmyAdmin. Jinými nástroji podobnými Accessu jsou projekt Kexi, DBDesigner pro pokročilé uživatele nebo Knoda pro uživatele KDE. Žádný z výše uvedených produktů není schopen číst Access soubory. Databáze integrovaná v balíčku OpenOffice (Base) není plně odladěná. Migrace tiskových služeb na OSS V malých kancelářských podmínkách je běžné mít připojenou tiskárnu na přímo k pracovní stanici. Větší kanceláře, ve kterých objem tisku ve větší, potřebují mít tiskárnu napojenou na síť, aby mohla být obsluhována tiskovým serverem. OSS řešení podporuje oba modely. •

Tiskový model ve Windows

Tisk ve Windows je realizován prostřednictvím menu z grafického rozhraní aplikace. Aplikace generují tiskový výstup tak, že používají proces, který je velmi podobný tomu, jak se zobrazují informace na obrazovce. Sada specifických tiskových ovladačů je používána operačním systémem, aby bylo možné generovat tok dat k tiskárně. Tyto ovladače jsou obvykle dodávány výrobcem tiskárny a musí být nainstalovány lokálně nebo na centrálním tiskovém serveru. V síťovém prostředí je lepší nakonfigurovat tiskový server, protože klienti nemusí být konfigurování ručně. Stále ale bude nutné připojit tiskárnu ke klientovi, což se musí udělat buď ručně nebo skriptem. •

Tiskový model v Linuxu

Linux převzal tiskový model od BSD Unix. Aplikace generují soubory nebo toky tiskových dat, které jsou předávány k manipulačnímu programu tiskárny, který přebírá zodpovědnost za tiskovou úlohu. Úloha může být postavena do fronty nebo transparentně přenesena na jiný počítač v síti. První Unix systémy neměly nezávislý interface pro generování tiskových dat, takže každá aplikace musela zahrnovat kód pro každý druh tiskárny, která měla fungovat. BSD tiskový systém byl vždy schopen plnit tiskové úlohy pomocí sady filtrů, takže lidé začali psát filtry, které byly schopné převést jeden tiskový jazyk do jiného, a tak zvýšili počet podporovaných tiskáren. Z laboratorních podmínek byl převzat PostScript, který se stal standardním nezávislým tiskovým jazykem. Většina Linux distributorů nyní nahrazuje BSD 84

tiskový systém novým balíčkem nazývaným Common Unix Printing System (CUPS), který podporuje Internet Printing Protocol (IPP) jako doplněk k tradičnímu lpr protokolu. Nový tiskový model funguje následovně: Aplikace generuje tiskové úlohy v PostScriptu Jakmile jsou tiskové úlohy předány tiskovému serveru, aplikace mohou žádat speciální vlastnosti, které jsou tiskárnou podporovány (duplexní tisk, přehýbání, děrování, sešívání atp.). Požadavky mají standardní formát, ale samozřejmě uspějí pouze pokud má tiskárna odpovídající hardware, aby tyto požadavky byla schopna vykonat. Úkoly mohou být spravovány lokálně na pracovní stanici nebo předány napřímě tiskovému serveru a uživatel se nemusí starat o to, jaká metoda byla zrovna použita. Tiskový systém může rozdělit tiskové úlohy mezi jednotlivé tiskárny v tiskové farmě. Tiskový server musí spouštět úlohy přes filtry, aby byl schopen úlohu konvertovat do formátu, který tiskárna požaduje, a kontrolovat komunikaci s tiskárnou. V dnešní době jsou podporovány stovky modelů tiskáren, které je možné používat z prostředí Linuxu s ekvivalentními nebo lepšími výsledky než poskytují původní ovladače. Ačkoliv PostScript je běžně využíván jako zprostředkující formát, CUPS může být konfigurován tak, aby podporoval téměř jakýkoliv formát, pro který existují filtry. V praxi to znamená, že formáty jako PDF, JPEG a další mohou jít do tisku na přímo, zatímco některé stránky přidávají tiskové filtry, aby se daly automaticky vytisknout v přednastaveném tiskovém módu. CUPS poskytuje rozhraní, které je kompatibilní s BSD lpr a také s System Vs lp. Tak je možné nahradit starší systémy úplně. CUPS nabízí celou řadu vlastností a možností zahrnujících automatické vyhledávání tiskových serverů, počítání stran, vytváření kvót atp. Nastavení tiskové služby v OSS Jen v určitých případech je velmi jednoduché nastavit přímo připojené tiskárny k pracovním stanicím. Ty mohou být sdíleny napříč sítí a CUPS takové řešení podporuje. Použití tiskových serverů je doporučováno pro případy, kdy dochází ke kumulování tiskových úloh v důsledku vyššího objemu tisku. Jeden nebo dva tiskové servery mohou být nainstalovány a přiřazeno jim logické jméno v DNS k jejich přirozeným „hostnames“. Použití logických názvů jako například tiskový server.nekde.cz než

c44.nekde.cz. všechny klientské počítače by

měly být překonfigurovány, aby odkazovaly na tyto servery pro jakékoliv tiskové požadavky, aby nemusely být v budoucnu re-konfigurovány, když bude přidána nebo odebrána nějaká tiskárna.

85

•

Tisk z Windows klientů připojených k Linuxovým tiskárnám

Existuje několik způsobů, jak nastavit Linuxové tiskové servery tak, aby podporovaly pracovní stanice pod Windows. •

Použití lpr protokolu

Tato metoda je vhodná v situacích, kdy se jedná o malé množství klientů, kteří musí být podporováni. lpr je běžným protokolem pro předávání tiskových úloh mezi Unixovými počítači. Jak bylo zmíněno dříve, tento protokol byl nahrazen IPP. Postup by měl být následující: 1. Ujistit se, že Linuxové počítač je nakonfigurován, aby akceptoval úlohy používající lpr 2. Získat vhodné Windows ovladače pro tiskárnu. Ideálně se může jednat o generické CUPS ovladače, které generují přenositelný PostScript, ale je možné použít jiné specifické ovladače, pokud je CUPS nastaven tak, aby umožňoval čistě tisk. 3. Přihlásit se do Windows jako administrátor 4. Otevřít Správce sítí v Kontrolním panelu a ujistit se, že „Microsoft TCP/IP tisk“ je zobrazen. Pokud není, pak se musí přidat (z instalačního CD) a poté restartovat. 5. Konfigurace tiskárny na Windows klienta jako by to byla lokální tiskárna (ne síťová!!!). Jakmile je vybírán port pro tiskárnu, je třeba vytvořit nový „LPT port“ a nakonfigurovat jej, aby posílal úlohy na tiskový Linux server. Windows klient nyní bude schopen posílat tiskové úlohy na Linuxový počítač, ale Windows nástroje nemusí být schopné vidět a spravovat tiskové fronty. CUPS podporuje webovou správu, takže uživatelé by měli být o této možnosti uvědoměni, pokud to je nutné. •

Použití sdílené tiskárny

Tato metoda je také vhodná pro malé skupiny Windows klientů. Nainstalovat a nakonfigurovat Samba na Linux server. Následovat instrukce pro vytváření sdílené tiskárny – je to snadné, protože Samba automaticky vytváří sdílení pro každou tiskárnu, o které server ví. Na každém Windows klientu použít Průvodce přidáním tiskárny (Add Printer Wizard) za účelem přidání tiskárny. Mělo by být možné procházet skrze seznam serverů a vybrat ten konkrétní, který má být použit. Bude nutné nainstalovat ovladače tiskárny lokálně na pracovní stanice. Pro zefektivnění tohoto schématu je možné, aby administrátor nahrál pomocí Průvodce přidáním tiskárny ovladače tiskárny na Samba server, takže nemusí být instalovány

86

individuálně na klientské počítače. •

Použití tiskové konfigurace

Tato metoda je vhodná pro větší instalace a v těch případech, kdy klientské počítače musí být konfigurovány méně zkušeným administrátorem. Zpočátku to je tento postup sice náročnější, ale později je to snazší. Protože je postup obsáhlejší, není zde popisován detailně. Plný návod je možné nalézt s sekci HowTo projektu Samba. 1. Nainstalovat a nakonfigurovat Samba na Linux server. Je třeba mít nainstalovanou verzi 3.0 a vyšší. 2. Nakonfigurovat CUPS, aby podporoval Windows tiskárny přidáním CUPS ovladače. 3. Použít cupsaddsmb, aby se nainstalovaly Windows ovladače z CUPS do Samba. 4. Připojit se z Windows klienta použitím ID, které má povolení modifikovat tiskové nastavení na serveru a nastavit výchozí tiskové vlastnosti (velikost stránky atp.). Je třeba si dát pozor na to, aby výchozí nastavení bylo skutečně výchozí! 5. Na každé pracovní stanici se vyhledá server. Po kliknutí na požadovanou tiskárnu se vybere „Připojit“. Tiskárna by se nyní měla zobrazit v seznamu lokálních tiskáren, a tak může být snadno použita. V případě rozsáhlých instalací je vhodnější použít logon skript, pro zefektivnění práce. •

Schémata migrace tisku

Pro menší kanceláře je snazší nastavit tiskový server na Linuxu, a pak rekonfigurovat pracovní stanice ručně. Pokud je připojeno ke sdílení několik tiskáren k jedné pracovní stanici, pak stojí za zvážení konsolidovat tuto architekturu a raději použít tiskový server. To může být mnohem snazší, pokud tiskárna podporuje ethernet karty. Paralelní tiskárny mohou být taktéž zasíťovány prostřednictvím síťových printer boxů. Větší kanceláře by měly prospěch z více než jednoho tiskového serveru. Tyto stroje mohou provádět také další úkoly, aby jejich výkonová kapacita byla efektivně využita. V případě většího tiskového zatížení je třeba vzít do úvahy, že převod PostScriptu je docela náročný na výkon CPU. Pro přechod z se starého tiskového serveru na nový pod Linuxem je vhodné použít „Point and Print“ konfiguraci Windows klientů, aby tento přechod na nový server se mohl odehrát jen jednoduchým login skriptem. Potenciální problémy Existuje několik problémů, které se mohou běžně vyskytovat, a tak je dobré jim předcházet: Ujistit se, že každá tiskárna je kontrolovaná pouze jedním serverem. všechny pracovní 87

stanice i servery by měly posílat tiskové úlohy přes kontrolní server, což je obzvláště důležité u síťových tiskáren. Pokud by kontrolní server nebyl nastaven, pak by dvě nebo více tiskových úloh ve stejnou dobu mohly přerušit výstup. Pokud to je možné, nastavit pouze jednu sadu ovladačů pro jednu tiskárnu, což se nejlépe realizuje právě prostřednictvím kontrolního serveru, ale není to nevyhnutelné. Další informace týkající se tisku Spousta informací o tisku je dostupná na internetu na stránkách www.cups.org, www.linuxprinting.org, aj. •

Legální aplikace

Tyto aplikace, které nemají OSS alternativu nemohou být rekompilovány a být provozovány pod OSS pouze s legálním operačním systémem nebo s emulátorem. •

Ochrana proti virům

Aktuální antivirová kontrola je důležitá pro prostřední Windows nebo Apple Macintosh. Na druhé straně bylo zaznamenáno velmi málo virů na OSS platformě a antivirová kontrola na Linuxu představuje spíše nástroj, který brání rozšiřování virů na jiné platformy. Tento způsob ochrany zahrnuje skenování emailů. V minulosti se vyskytlo několik ataků na OSS systémy (nejznámější byl tav. Morris Worm), avšak riziko napadení bylo již před léty eliminováno. Antivirová ochrana je v tomto ohledu nástrojem prevence, protože nikdo nemůže zaručit, kdy se nějaký nový virus objeví. |Dobře řízené prostředí a disciplinovaní uživatelé jsou tou nejlepší antivirovou ochranou. Nejznámějšími OSS antivirovými projekty jsou ClamAV a Open Anti Virus, který však výrazně zaostává. Spousta komerčních antivirových produktů může být provozována i na OSS platformách. Tyto produkty nejsou totožné s verzemi pro Windows, protože to vzhledem k výše uvedenému není úplně nutné, nicméně např. kvalitní mail scanning může být žádoucí.

6.2. Scénář č. 2 – Unix Organizace používá Unix servery (Solaris, H/UX, AIX, OSF/1 aj.), používá pracovní stanice s klient-server aplikacemi. Některé pracovní stanice používají X Terminály. Migrace z pracovních stanic je podobná pro scénář 1 uvedený výše. Pracovní stanice a X terminály, které provozují aplikace na X základě, budou s velkou pravděpodobností fungovat i na nových OSS pracovních stanicích. Hlavním problémem tak zůstává přechod ze serverů. 88

Přechod z Unixu na Linux je velmi podobný k portování z jedné verze Unixu na druhou. Je třeba mít ta paměti, že Unix zahrnuje AT&T, BSD a OSF/1 kódy, které jsou různými implementacemi POSIX standardů – podobně jako Linux. Rozdíly nastávají, pokud program používá vlastnosti, které jsou mimo POSIX. Typicky se jedná o systémovou administraci nebo vlastnosti, které ovlivňují výkonnost. Špatně napsané programy, které nezohledňovaly POSIX, mohou mít taktéž problémy. Problémy se však vyskytují v detailech, než aby se jednalo o zásadní problémy na úrovni architektury. Unix požívá otevřené protokoly jako TCP/IP a používá běžné služby jako DNS nebo DHCP. Konfigurace je taky odlišná. Systémová data jsou s velkou pravděpodobností držena v jiných než proprietárních formátech, takže jejich uzpůsobení požadavkům Linuxu bude docela snadné. Toto se týká i uživatelských jmen a hesel, ale kvůli drobným rozdílům není přímý transfer možný. Pokud je k dispozici zdrojový kód, pak rekompilace by měla umožnit kód naportovat. Musí být splněny některé body: •

Neexistuje standard pro lokaci souborů, a proto může být problém kódovat tuto lokaci do programů (např. /usr/bin, /usr/local/bin, /opt/bin).

•

Mohou existovat různé hodnoty pro systémové konstanty – např. maximální počet souborů, které mohou být otevřeny v určitém čase aj.

•

Dílčí rozdíly v programovacím jazyku např. ksh a pdksh. Různé kompilátory C mohou být méně striktní, co se týče kontroly syntaxe, proto kód, který na jednom počítači funguje nemusí

zákonitě

fungovat

na

jiném.

Kód může být neportovatelný např. z důvodu: •

Neportovatelné použití konstanty (číslo místo SIGPIPE aj). Tento příklad může nastat pokud programátor používá jiný než POSIX standard.

•

Délka slova

•

gcc kompiler na Linuxu je v tomto ohledu docela flexibilní

•

Každý Unix může mít různé hlavičky souborů a knihoven. Mohou být i v různém umístění. Umístění a názvy mohou být změněny automaticky jakmile jsou nalezeny. Nicméně pokud knihovny nebo hlavičky souborů nabízejí různé chování, pak manuální zásahy jsou nevyhnutelné. Typické situace jsou např.:

•

Odlišnosti v sémantice volání knihoven o

u vláken

o

exec (setuid bit na skripty je ignorován)

o

asynchronní I/O

89

•

o

ioctl pro tty kontrolu

o

různé hodnoty pro errno

Originální kód může využívat proprietární aplikace nebo knihovny, které nejsou dostupné pod Linuxem, proto musí být přepsány podle toho, co v Linuxu dostupné je. To se může týkat například speciálního hardware.

•

Nástroje, které pomáhají vytvářet aplikace musí být z výše uvedených důvodů aktualizované.

•

Aplikace mohou vytvářet domněnky o specifických subsystémech jako např. tisk a databáze. To znamená, že např. SQL kód musí být přepsán.

•

Portování jakéhokoliv kódu pro nový hardware, kompiler nebo operační systém může vykazovat chyby v programu, ve kterém byly vždy, ale nemusely se projevit např. kvůli paměti, která byla jinak alokována nebo integers mají jiné velikosti, či byty jsou jinak řazeny.

Další

informace

je

možné

nalézt

mimo

jiné

na

uvedených

odkazech.

http://www.linuxhq.com/guides/LPG/node136.html http://www-1.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130115.pdf http://www.unixporting.com/porting-guides.html

6.3. Scénář č. 3 – Mainframe Administrace mainframe (MVS, VM/CMS, AS/400, aj.) probíhá prostřednictvím tzv. „zelených obrazovek“. Přestože jsou používány i PC, převážně se jedná o terminálovou emulaci s několika málo lokálními aplikacemi. Scénář přechodu je podobný jako u tenkého klienta, protože architektura je také velmi podobná. Migrace serverů je rozsáhlejší problematika, která si vyžaduje samostatný přístup nad rámec tohoto informačního balíčku.

6.4. Scénář č. 4 – Tenký klient Administrátoři používají tenké klienty s přístupem přes Citrix nebo podobný program a kombinací Windows a Unix aplikací. Používání BRA není pro účely tohoto materiálu považováno za důvod k používání klientského modelu, avšak pokud je přistoupeno k BRA, pak vyvstává řada problémů jako ve Scénáři 1. Migrace v tomto scénáři vychází z představy, že se nebude měnit architektura. 90

Protože klient bude velmi tenký, bude požadováno pouze, aby byl použit OSS prohlížeč pro každý požadovaný protokol. Následující protokoly mohou být podporovány: •

HTTP. V tomto případě je postačující jakýkoliv OSS prohlížeč. V otázkách dalších plugins a skriptů je třeba si ověřit.

•

ICA. Toto je proprietární protokol Citrix, který je sice nabízen zdarma, avšak není OSS.

•

RDP. Protokol používaný Windows Terminal Server. OSS prohlížeč RDP je k dispozici pod názvem např. rdesktop.

•

VT220, VT100 aj. Tyto DEC protokoly jsou podporovány xterm, zatímco je používán vhodné TERM prostředí pro různé nastavení. Připojení k hostovi je prostřednictvím telnetu. xterm může emulovat terminály různých typů změnou hodnoty TERM variable. Například nastavení TERM=prlsm9 bude emulovat protokol používaný PRIME počítači. Veškeré emulace předpokládají telnet konektivitu nebo podobnou a také znakový spíše než grafický protokol.

•

3270. Tento program nabízí vhodnou podporu. Připojení k hostovi je prostřednictvím telnetu.

•

X. Toto je nativní zobrazovací protokol pro Linux.

Linux Terminal Server Project (LTSP) nabízí celou řadu sad nástrojů pro vytvoření tenkých klientů na Linuxu. Tento projekt je aktivní a kvalita vytvořeného software se zdá být velmi dobrá. V případě potřeby změn na straně serveru je vhodné zohlednit veškeré situace, které byly popsány výše a nechat se inspirovat dalšími scénáři.

91

7. Přílohy Seznam zkratek ACL

Access Control List.

API

Application Programming Interface

ASP

Active Server Pages

BDC

Backup Domain Controller.

BC

Beta Code

CIL

Common Intermediate Language.

CLR

Common Language Runtime or CLR.

CLI

Common Language Infrastructure

CPU

Central Processing Unit

DBMS

Database Management System

DEC

Protocol The Digital Equipment Corporation

DHCP

Dynamic Host Configuration Protocol

DNS

Domain Name Server

FTP

File Transfer Protocol

GPL

General Public License

GUI

Graphical User Interface

HTTP

Hypertext Transfer Protocol

JDBC

Java Database Connectivity

LDAP

Lightweight Directory Access Protocol

LGPL

Lesser General Public License

MAA

Mail Access Agent

MDA

Mail Delivery Agent

MTA

Mail Transport Agent

MUA

Mail User Agent

ODBC

Open Database Connectivity

OSS

Open Source Software

PDA

Personal Digital Assistant

PDC

Primary Domain Controller

PHP

Hypertext Preprocessor

PKI

Public Key Infrastructure

SMB

Server Message Block

SMS

Short Message Service

92

SQL

Structured Query Language

SSL

Secure Sockets Layer

TLS

Transport Layer Security

W3C

World Wide Web Consortium

WebDAV

World Wide Web Distributed Authoring and Versioning

XML

Extensible Markup Language

93

8. Užitečné odkazy a literatura http://www.vasemoznosti.cz http://www.root.cz http://www.opensource.org http://www.openoffice.cz http://www.gnu.org/philosophy/categories.html http://www.winehq.com/ http://appde.winehq.com/ http://www.cynergi.net/exxportsql http://www.kitebird.com http://www.cups.org http://www.linuxprinting.org http://www.linuxhq.com/guides/LPG/node136.html http://www-1.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130115.pdf http://www.unixporting.com/porting-guides.html http://www.wikipedia.org http://www.distrowatch.org http://www.sourceforge.net

94