Hardwarová realizace. systému

ˇ ˇ VYSOKÉ UCENÍ TECHNICKÉ V BRNE Fakulta elektrotechniky a komunikaˇcních technologií Ústav biomedínského inženýrství

Hardwarová realizace nemocniˇcního informaˇcního systému

Student: Bc. Jan FRIEDL Vedoucí práce: Ing. Petr FEDRA BRNO 2008

Obsah 1 Úvod

6

2 Svobodný software

7

2.1

Richard Matthew Stallman . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2

GNU projekt

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3

Nadace pro svobodný software . . . . . . . . . . . . . . . . . . . . . . .

8

2.4

Linus Benedict Torvalds

2.5

GNU/Linuxové distribuce

2.6

Co jsou to balí£ky a balí£kovací systémy

. . . . . . . . . . . . . . . . .

11

2.7

Adresá°ová strukruta . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.8

Red Hat Enterprise Linux

. . . . . . . . . . . . . . . . . . . . . . . . .

13

2.9

Live distribuce Slax . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

. . . . . . . . . . . . . . . . . . . . . . . . . .

9

. . . . . . . . . . . . . . . . . . . . . . . . .

10

2.10 Výhody a vyuºití Slaxu . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.11 Tenký klient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.12 Jak funguje tenký klient

20

. . . . . . . . . . . . . . . . . . . . . . . . . .

3 Informa£ní systémy

21

3.1

Historický p°ehled uplatn¥ní po£íta£· v medicín¥

. . . . . . . . . . . .

22

3.2

Vyuºití výpo£etní techniky ve zdravotnictví

. . . . . . . . . . . . . . .

24

3.3

Informa£ní systémy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.4

P°enos informací v IS . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4 Nemocni£ní informa£ní systém

27

4.1

Pouºívané technologické architektury NIS . . . . . . . . . . . . . . . . .

27

4.2

P°ipojení k databázím NIS . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.3

P°ínosy NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.4

Nemocni£ní informa£ní systém v eské republice . . . . . . . . . . . . .

29

5 Clinicom

31

5.1

Základní pilí°e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5.2

Specializované moduly systému

. . . . . . . . . . . . . . . . . . . . . .

32

5.3

Uºivatelská rozhraní systému . . . . . . . . . . . . . . . . . . . . . . . .

32

5.4

Databázová platforma CACHE

33

. . . . . . . . . . . . . . . . . . . . . .

6 Hardwarové nároky serveru

34

6.1

Monitorování po£tu p°ipojení

. . . . . . . . . . . . . . . . . . . . . . .

34

6.2

Vykreslení po£tu p°ipojení . . . . . . . . . . . . . . . . . . . . . . . . .

36

6.3

Monitorování zatíºení . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

6.4

Strategie p°id¥lování pam¥ti

39

. . . . . . . . . . . . . . . . . . . . . . . .

7 e²ení neo£ekávané události 7.1

Záloºní napájení

7.2

Detekce výpadku elektrické energie

40

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40 41

8 Realizace tenkého klienta

44

8.1

Vytvo°ení klávesové mapy

. . . . . . . . . . . . . . . . . . . . . . . . .

44

8.2

Keycode kláves

8.3

P°ipojení ssh k NIS Clinicom

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45 47

8.4

Vytvo°ení modulu pro Slax . . . . . . . . . . . . . . . . . . . . . . . . .

48

9 Záv¥r

49

10 P°ílohy

51

10.1 Skript posílání zpráv o výpadku . . . . . . . . . . . . . . . . . . . . . .

51

10.2 Skript statistika p°ihlá²ení . . . . . . . . . . . . . . . . . . . . . . . . .

51

10.3 Skript grafy a vykreslení grafu . . . . . . . . . . . . . . . . . . . . . . .

53

10.4 Skript monitorování zatíºení . . . . . . . . . . . . . . . . . . . . . . . .

57

10.5 Obrázky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

ABSTRAKT Pˇredkládaná práce se zabývá problémem efektivnˇejšího využití nejen hardware, ale i svobodného software. Na zaˇcátku práce jsou obecnˇe pˇredstaveny svobodné GNU/Linuxové distribuce, pˇriˇcemž práce je zamˇeˇrena na dvˇe distribuce. První je Red Hat Enterprise Linux, který je nasazen na serveru nemocniˇcního informaˇcního systému Clinicom. Druhou je live distribuce Slax, která je použita pro testování terminálového pˇripojení k nemocniˇcnímu informaˇcnímu systému Clinicom. Druhá cˇ ást práce se obecnˇe zamˇeˇruje na nemocniˇcní informaˇcní systém, kde na konci pˇredstavuje konkrétní rˇešení od firmy SMS. Jedná se o již zmínˇený nemocniˇcní informaˇcní systém Clinicom. Další cˇ ást je zamˇeˇrena na monitorování vytížení serveru. Sleduje jak pˇrihlášení jednotlivých uživatel˚u, tak i množství alokované pamˇeti. Dále studuje problematiku ˇrešení neoˇcekávané události, jako je napˇríklad výpadek dodávky elektrického proudu, a popisuje jedno konkrétní rˇešení. Poslední cˇ ást se soustˇredí na realizaci zabezpeˇceného pˇripojení k nemocniˇcnímu informaˇcnímu systému Clinicom a pˇredstavuje live distribuci Slax jako software využitý pro tenkého klienta. ABSTRACT The presented work concerns problems of more effective using hardware and also free software. The first part of my work presents generally free GNU/Linux distributions and this part is concentrated on two distributions. The first is Red Hat Enterprise Linux which is installed in the server of the hospital information system Clinicom. The second is live distribution Slax that is used for testing of terminal connection to the hospital information system Clinicom. The second part of my work is generally concentrated on the hospital information systems and there is presented the firm SMS solution at the end. It is the hospital information system Clinicom. The next part is generally concentrated on the workload server monitoring. It monitors both userlogins and allocated memory size. Then there are discused problems of solution of unthought-of events, for example blackout, and the one solution is described there. The last part is concentrated on implementation of the security connection to the hospital information system Clinicom and it presents live distribution Slax as distribution for thin client.

3

Klíˇcová slova Svobodný software, GNU/Linux, Red Hat Enterprise Linux, live distribuce, GNU/Linux Slax, modul, tenký klient, nemocniˇcní informaˇcní systém, Clinicom, textový terminál, Netaccess, Carecenter, statistika pˇrihlášení, gnuplot, PID, cmdline, status, VmSize, APCUPSD, onbattery, keycode, scancode, Linux terminal server project. Keywords Free software, GNU/Linux, Red Hat Enterprise Linux, live distribution, GNU/Linux Slax, modul, thin client, hospital information system, Clinicom, text terminal, Netaccess, Carecenter, login statistik, gnuplot, PID, cmdline, status, VmSize, APCUPSD, onbattery, keycode, scancode, Linux terminal server project.

ˇ Bibliografická citace diplomové práce dle CSN ISO 690: FRIEDL, J. Hardwarová realizace nemocniˇcního informaˇcního systému. Brno: Vysoké uˇcení technické v Brnˇe, Fakulta elektrotechniky a komunikaˇcních technologií, 2008. 65 s. Vedoucí diplomové práce Ing. Petr FEDRA.

4

PROHLÁŠENÍ Prohlašuji, že svou diplomovou práci na téma „Hardwarová realizace nemocniˇcního informaˇcního systému“ jsem vypracoval samostatnˇe pod vedením vedoucího diplomové práce s použitím odborné literatury a dalších informaˇcních zdroj˚u, které jsou všechny uvedeny v seznamu literatury na konci práce. V Brnˇe dne 23. kvˇetna 2008 Jan FRIEDL

ˇ PODEKOVÁNÍ: Dˇekuji vedoucímu diplomové práce Ing. Petru FEDROVI za úˇcinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady pˇri zpracování mé diplomové práce.

5

1

Úvod

Právˇe v dnešní dobˇe, když se vše zdražuje a každá vláda se snaží všude ušetˇrit, tak vzniká i problém, jak financovat d˚uchody, sociální zabezpeˇcení a zdravotnictví. Nejen tato skuteˇcnost vede ke vzniku nových reforem. Právˇe zmínˇené zdravotnictví je obor, který se snažili a snaží ministˇri upravit reformami tak, aby se, co možná z nejvˇetší míry, financovalo samo. Proto je v dnešní dobˇe nejen na pacientech, aby vzali v potaz jejich zdravotní situaci a nechodili k lékaˇru˚ m na „kus rˇeˇci“, ale je to též na zdravotních institucích a na ministerstvu zdravotnictví. Právˇe zdravotní instituce a ministerstvo zdravotnictví by mˇely zvážit možnost, jak efektivnˇeji využít stávající hardware v nemocnicích. Tato práce pˇredkládá možnosti efektivnˇejšího využití nejen hardware, ale i svobodného software. Diplomová práce nejprve pˇredstavuje svobodné operaˇcní systémy založené na GNU/Linux (GNU Není Unix). Dále se zamˇerˇuje na dvˇe distribuce a to operaˇcní systém Red Hat Enterprise Linux, který je nasazen na serveru nemocniˇcního systému Clinicom. Druhým operaˇcním systémem je live distribuce Slax, která je použita pro testování terminálového pˇripojení k nemocniˇcnímu informaˇcnímu systému Clinicom a také protože využití „tenkých“ klient˚u ve školní síti nebylo možné realizovat. V další cˇ ásti, práce seznamuje cˇ tenáˇre s nemocniˇcním informaˇcním systémem (NIS) a poté se zamˇerˇí na NIS Clinicom. Na tuto kapitolu navazuje kapitola o vytížení serveru pˇri využití terminál˚u v laboratoˇri lékaˇrské informatiky. Poslední cˇ ástí je ˇrešení neoˇcekávané události, jako je výpadek dodávky elektrického proudu.

6

2

Svobodný software

Svobodný software [1] (anglicky free software) je software, ke kterému je k dispozici také zdrojový kód, spolu s právem tento software používat, modifikovat a distribuovat. Naprostá vˇetšina svobodného software je zdarma, aˇckoliv to není podmínkou. První start mu dal v roce 1984 Richard Stallman, kdy založil projekt GNU. Tento projekt mˇel za cíl vytvoˇrit kompletní unixový operaˇcní systém založený na svobodném software. Jako krédo svobodného software definoval cˇ tyˇri svobody: • svoboda používat program za jakýmkoliv úˇcelem • svoboda studovat, jak program pracuje a možnost pˇrizp˚usobit ho svým potˇrebám • svoboda redistribuovat kopie programu • svoboda vylepšovat program a zveˇrejˇnovat zlepšení, aby z nich mohla mít prospˇech celá komunita Za získání kopií svobodného software m˚užete platit, nebo je obdržet zdarma. Ovšem bez ohledu na zp˚usob, jak jste je získali, máte vždy svobodu kopírovat a mˇenit software, dokonce prodávat nebo darovat jeho kopie nebo pozmˇenˇené verze. 2.1

Richard Matthew Stallman

Richard Matthew Stallman [2] (* 16. bˇrezna 1953, Manhattan, New York), známý též pod iniciálami RMS, je zakladatel projektu GNU, hnutí svobodného softwaru a v ˇríjnu 1985 také Nadace svobodného softwaru (Free Software Foundation). Aby ochránil ideály hnutí GNU, pˇrišel Stallman s konceptem tzv. copyleftu, jehož princip uplatnil v široce užívané softwarové licenci GPL. 2.2

GNU pro jekt

GNU1 je projekt zamˇeˇrený na svobodný software, inspirovaný operaˇcními systémy unixového typu. P˚uvodní cíl byl vyvinout operaˇcní systém se svobodnou licencí, který však neobsahuje žádný kód p˚uvodního Unixu. Jeho jméno je rekurzivní zkratka pro GNU’s Not Unix. Oznaˇcení GNU je používáno také pro souhrn program˚u, které poskytuje a dodává Free Software Foundation. Tento souhrn program˚u je také cˇ asto oznaˇcován pˇrímo jako „operaˇcní systém GNU“. 1 Slovo gnu v angli£tin¥ znamená téº pak·¬, proto byl pak·¬ vybrán maskotem projektu GNU.

7

Pojmenování operaˇcní systém GNU se podaˇrilo naplnit až v roce 1992, kdy byla doplnˇena poslední chybˇející souˇcást tohoto operaˇcního systému.Touto cˇ ástí bylo jádro (kernel), které nezávisle vytvoˇril Linus Benedikt Torvalds. Toto jádro dostalo název Linux. Operaˇcní systém GNU používal do té doby jádro HURD, jehož vývoj byl a je velice pomalý a složitý. Jádro HURD se zatím neprosadilo. Aˇckoliv se operaˇcnímu systému GNU s jádrem Linux cˇ asto ˇríká jen Linux, pˇresnˇejší pojmenování je však GNU/Linux. Z toho vyplývá, že operaˇcní systém GNU m˚uže používat i jiná jádra, napˇr. jádro Hurd (systém se pak nazývá GNU/Hurd) vyvíjené v rámci projektu GNU nebo jádro Solaris vyvinuté spoleˇcností Sun Microsystems (GNU/Solaris). Dnes rˇídí chod GNU Free Software Foundation. 2.3

Nadace pro svobodný software

Nadace pro svobodný software (Free Software Foundation) se stará o právní a organizaˇcní stránky projektu GNU a o rozšiˇrování povˇedomí o svobodném software. Myšlenky svobodného software byly formulovány prostˇrednictvím copyleft GNU General Public License a GNU Lesser General Public License (p˚uvodnˇe nazývaná GNU Library General Public License), které se cˇ asem staly nejrozšíˇrenˇejšími licencemi svobodného software.

GNU General Public License GNU General Public License (GPL) zajišt’uje uvedené základní svobody svobodného software. Nˇekdy je také nazývána copyleft licencí. GPL licence rˇíká, že pokud redistribuujete originální nebo pozmˇenˇenou verzi programu, musíte tuto verzi redistribuovat pod stejnou licencí, s jakou jste získali p˚uvodní program. V podstatˇe to znamená, že k nˇemu nesmíte pˇridat žádná omezení, abyste tak neodepˇreli základní svobody ostatním. Tato licence tedy nijak neomezuje základní svobody, spíše je chrání. Svobodný software neznamená nekomerˇcní. Svobodný program musí být dostupný pro komerˇcní využití. Komerˇcní vývoj svobodného software není niˇcím neobvyklým, takové programy jsou komerˇcním svobodným software.

Co je to copyleft Copyleft je hlavním ˇrešením, jak udˇelat z programu svobodný software a požadovat, aby všechny jeho modifikace a rozšíˇrené verze byly rovnˇež svobodným softwarem. Nejjednodušší zp˚usob jak uˇcinit program svobodným je udˇelat z nˇej public domain2 , 2 Tento pojem znamená, ºe autor díla se rozhodl, ºe dovolí svoje dílo voln¥ uºívat, bez nároku na dal²í ochranu díla. V £eském právním systému se nikdo nem·ºe vzdát svých (autorských) práv, je pouze moºné nabídnout ve°ejnosti bezúplatnou licenci na libovolné uºití díla, ale lze kaºdopádn¥

8

bez copyrightu. To umožní lidem sdílet program a jeho vylepšení, jestliže chtˇejí. Také však dovoluje nespolupracujícím lidem zmˇenit program na proprietární software. Mohou udˇelat zmˇeny, hodnˇe nebo jen pár, a distribuovat výsledek jako proprietární produkt. Lidé, kteˇrí dostanou program v takto modifikované podobˇe, nemají svobodu, kterou jim dal p˚uvodní autor, prostˇredník ji odstranil. Copyleft rˇíká, že kdokoli redistribuuje software se zmˇenami cˇ i beze zmˇen, musí ponechat svobodu k dalšímu kopírování a zmˇenám. Copyleft zaruˇcuje, že každý uživatel má svobodu. Copyleft také poskytuje pobídku pro ostatní programátory, aby se pˇridali k svobodnému software. D˚uležité svobodné programy, jako tˇreba GNU C++ pˇrekladaˇc, existují jen díky tomu. Copyleft také pomáhá programátor˚um, kteˇrí chtˇejí pˇrispˇet vylepšením k svobodnému software, dává jim volnost to udˇelat. Tito programátoˇri cˇ asto pracují pro spoleˇcnosti nebo univerzity, které by udˇelaly témˇerˇ cokoli, aby získaly víc penˇez. Programátor m˚uže chtít pˇrispˇet zmˇenami k programu, ale jeho zamˇestnavatel m˚uže chtít zmˇenit software na proprietární softwarový produkt. Vývojáˇri proprietárního softwaru používají copyright, aby vzali uživateli svobodu. My používáme copyleft, abychom jim tuto svobodu zaruˇcili. To je d˚uvod proˇc se obrací název naruby, mˇení se „copyright“ na „copyleft“. 2.4

Linus Benedict Torvalds

Linus Benedict Torvalds (* 28. prosince 1969) v roce 1991 zapoˇcal vývoj svého jádra, které nakonec dostalo jméno „Linux“3 . P˚uvodnˇe ho zaˇcal psát finský student helsinské univerzity Linus Torvalds jako sv˚uj koníˇcek. Torvalds vycházel z Minixu, což byl zjednodušený klon Unixu napsaný Andrewem Tanenbaumem pro úˇcely výuky návrhu operaˇcních systém˚u. Avšak Tanenbaum nikomu nedal svolení k úpravám svého systému, a tak Torvalds napsal vlastní náhradu Minixu. Linux zaˇcal jako emulátor terminálu napsaný v IA-32 assembleru a jazyce C, který byl pak zkompilován do binární podoby a nabootován z diskety, takže mohl bˇežet mimo p˚uvodní operaˇcní systém. V srpnu roku 1991 publikoval Linus sv˚uj výtvor v diskusní skupinˇe comp.os.minix. První verze linuxového jádra (0.01) byla vydána na Internetu 17. záˇrí 1991 pod licencí GPL, další následovala v rˇíjnu téhož roku. Od té doby se na tomto projektu podílely tisíce vývojáˇru˚ z celého svˇeta. p°edpokládat, ºe autor, který svoje dílo takto ozna£il, se svých práv nebude domáhat.

3 Jeho osobním maskotem je buclatý tu£¬ák p°ezdívaný Tux, jenº byl komunitou adoptován jako

maskot GNU/Linuxu.

9

Mnoho lidí m˚uže namítat, že svobodný software vede k vˇetšímu zájmu hacker˚u. Opak je však pravdou a tzv. Linus˚uv zákon (Linus’s law) to velice vystihuje: „Je-li dost oˇcí, jsou všechny chyby malé. (Given enough eyeballs, all bugs are shallow.) Velká chyba se velmi tˇežko hledá, ale hledá-li ji hodnˇe lidí, je nadˇeje (a taky už zkušenost), že žádná chyba nebude velká.“

Spojení Linus a Linux P˚uvodnˇe Linus používal operaˇcní systém Minix, který pozdˇeji nahradil svým vlastním OS. Linus mˇel v plánu nazvat systém jako Freax (kombinace slov „free“ (svobodný), „freak“ (výstˇrední, mimoˇrádný) a písmene X jako oznaˇcení systému unixového typu). Pojmenování však na FTP serveru bylo Linux (jako Linus˚uv Minix). Toto se natolik vžilo, že z˚ustalo pojmenování až doposud. Souˇcasné Linuxové jádro obsahuje jen nˇeco okolo 2% kódu napsaného samotným Linusem. Navzdory relativní míˇre jeho pˇrínosu z˚ustává Linus Torvalds hlavní autoritou v tom, který kód se do jádra dostane. Torvalds má ve zvyku nezúˇcastˇnovat se debat, které se netýkají jádra. Kombinací Linuxového jádra a software vyvíjeného mnohými dalšími (pˇrevážnˇe pod projektem GNU) vzniká tzv. GNU/Linuxová distribuce. 2.5

GNU/Linuxové distribuce

ˇ Zpoˇcátku byl GNU/Linux vyvíjen a používán zejména jednotlivými nadšenci. Casem ale získal podporu velkých spoleˇcností jako IBM, Hewlett-Packard a Novell pro využití na serverech, a poslední dobou získává popularitu i na desktopovém trhu. Zastánci a analytici pˇripisují jeho úspˇech nezávislosti na dodavateli, nízkých nákladech, flexibilitˇe, bezpeˇcnosti a spolehlivosti. GNU/Linux byl p˚uvodnˇe vyvíjen pro poˇcítaˇce s procesory architektury i386 (tedy 80386 a kompatibilními). Dnes ale podporuje všechny populární poˇcítaˇcové architektury i mnoho z tˇech ménˇe obvyklých. Používá se v ˇradˇe zaˇrízení od embedded systém˚u (jako mobilní telefony, roboti cˇ i multimediální pˇrehrávaˇce), pˇres osobní poˇcítaˇce až po superpoˇcítaˇce. R˚uzné distribuce byly vyvinuty k r˚uzným úˇcel˚um. Mezi tˇemito distribucemi najdeme systém, který je hotový a pˇripraven k použití, lokalizaci a podporu urˇcité poˇcítaˇcové architektury.

Typy GNU/Linuxových distribucí Všechny distribuce mají stejný základ [3].

10

Typická distribuce obsahuje linuxové jádro, urˇcité GNU knihovny a nástroje, pˇríkazové shelly a tisíce balíˇck˚u aplikaˇcního softwaru - tj. od kanceláˇrských balík˚u, grafického prostˇredí, pˇres kompilátory r˚uzných jazyk˚u, textové editory až po vˇedecké nástroje. Liší se však „obalem“ (tzn. instalátorem) a „složením“ (tzn. software, unikátní úpravy). V souˇcasné dobˇe existuje kolem 450 r˚uzných distribucí. Proˇc je tolik distribucí? Odpovˇed’ je snadná: Snad všechny distribuce vznikly jako úprava již existující distribuce. Pak mluvíme o tzv. - based distribucích, napˇr. Red Hat - based. Skoro všechny distribuce vycházejí z Debianu, Red Hatu nebo Slackware. Distribuce se dˇelí podle r˚uzných mˇerˇítek. Nˇekteré jsou komerˇcní (Red Hat Enterprise Linux, Madriva, SuSE Linux Enterprise ...) - jsou totiž dodávány s technickou podporou. Za jinými zase stojí linuxová komunita (Debian, Gentoo,...). Další jsou vhodné pro kanceláˇrskou nebo domácí práci, nˇekteré zas pro budování server˚u, ostatní slouží jen pro jednu cˇ innost (pˇrehrávání DVD) a nebo jsou zcela univerzální. Vˇetšinou jsou distribuce bezplatnˇe šiˇritelné (download z internetu), ale na druhé stranˇe existují distribuce, za které se platí tisíce korun až tisíce dolar˚u (podnikové verze). Speciálními typy distribucí jsou tzv. malé, lehké distribuce (Damn Small Linux, DevilLinux, ...). Jsou vhodné pro použití na starších poˇcítaˇcích a živé (live) distribuce (Slax, Knoppix, ...). Live distribuce lze použít napˇríklad, když nechceme distribuci instalovat, ale pouze vyzkoušet. Další možností využití je, když chceme pracovat ve své oblíbené distribuci a spustit ji kdekoli budeme. Tyto distribuce je možné spustit z CD-ROM˚u, DVD-ROM˚u a Flashdisk˚u. Jaké programy budou v live distribucích, je dáno autorem. U vˇetšiny live distribucí je však možnost vybrat si programy, které chceme a využijeme. Toto si ukážeme pro live distribuci Slax v kapitole 2.9. 2.6

Co jsou to balí£ky a balí£kovací systémy

Stejnˇe tak, jako operaˇcní systém Windows používá své exe programy, tak GNU/Linuxové distribuce používají balíˇcky a zdrojové kódy. Zdrojové kódy jsou programy napsané v jazyce C, C++, Perl, Python. Tyto zdrojové kódy jsou urˇceny pro kompilaci a instalaci na vˇetšinu distribucí GNU/Linuxu, pˇri splnˇení urˇcitých závislostí. Kompilace znamená, že program zkonfigurujeme a pˇripravíme pro instalaci. Z toho vyplývá, že takto vytvoˇrený program je „ušit“ pˇrímo na míru našeho operaˇcního systému. Kdybychom mˇeli takto každý program, který používáme, kompilovat a instalovat, zabere to tolik cˇ asu a úsilí, že by trvalo nainstalování jednoho poˇcítaˇce rˇádovˇe dny až desítky

11

dn˚u. Z tohoto d˚uvodu zaˇcali jednotlivé distribuce šíˇrit a používat již pˇripravené a zkompilované programy v zabalené (zkomprimované) podobˇe. Právˇe takto upravenému zdrojovému kódu se rˇíká balíˇcek. Balíˇcek se pozná podle toho, že jeho jméno obsahuje název programu, verzi, poˇcítaˇcovou architekturu, pro kterou je urˇcen, a konˇcí koncovkou rpm, tgz nebo deb. Balíˇcek rpm, je p˚uvodnˇe zkratka Red Hat Package Management, dnes RPM Package Management. Tento typ balíˇcku, jak už z názvu vyplývá, založil Red Hat a v dnešní dobˇe jej používá hodnˇe distribucí. Dalším typem balíˇck˚u je balíˇcek s koncovkou tgz. Toto jsou balíˇcky, které vznikly tak, že se nejdˇrív dané soubory a adresáˇre spojily pomocí utility tar do jednoho celku, který se pak pomocí další utility gzip zkomprimoval. Z toho vznikne tedy pˇrípona .tgz. Tento typ balíˇck˚u používá napˇríklad distribuce Slackware. Posledním typem je balíˇcek deb. Ze zkratky vyplývá, že se jedná o balíˇcek debianu a distribucí na debianu založených. Pro každý typ balíˇcku je navržen speciální balíˇckovací systém. Balíˇcky sami o sobˇe neulehˇcí práci administrátora, ale lépe s nimi pracují externí programy. Proto také vznikly balíˇckovací systémy, které již ulehˇcili správu balíˇck˚u, aktualizací a závislostí. 2.7

Adresá°ová strukruta

GNU/Linuxová adresáˇrová struktura je odlišná od struktury Windows. Adresáˇrová struktura GNU/Linuxu, je zobrazena na obrázku 1. Zde vidíme, že existuje tzv. Koˇrenový adresáˇr (oznaˇcován /). Toto je hlavní adresáˇr, žádný nadˇrazený adresáˇr neexistuje, ze kterého dále vyr˚ustá vlastní struktura vnoˇrených adresáˇru˚ - adresáˇrový strom. Když napíšeme, že máme vytvoˇrit adresáˇr /tmp/aaaa, tak víme, že v koˇrenovém adresáˇri máme adresáˇr /tmp a tam vytváˇríme podadresáˇr aaaa. V GNU/Linuxu se nesetkáte s písmeny oznaˇcujícími jednotlivé disky, každé diskové zaˇrízení je pˇripojeno do urˇcitého adresáˇre a pracuje se právˇe s tímto adresáˇrem. Adresáˇre slouží ˇ pro lepší organizaci místa na disku. Casto se celý disk pˇrirovnává ke skˇríni a adresáˇre k jednotlivým poliˇckám nebo krabicím, do nichž ukládáte své vˇeci - soubory. V každém GNU/Linuxu je tato základní adresáˇrová struktura stejná. Do této základní struktury m˚užeme adresáˇre pˇridávat, ale mˇenit názvy a mazat adresáˇre se nedoporuˇcuje. Nebudu zde popisovat celou adresáˇrovou strukturu, ale vyzdvihnu jen nˇekteré adresáˇre. Zaˇcnu adresáˇrem /dev. Zde najdeme disková, textová a vstupní zaˇrízení, se kterými GNU/Linux pracuje. Dalším je /home, kde jsou pod jmény uživatel˚u vytvoˇreny jejich domovské adresáˇre. Zvláštním domovským adresáˇrem je adresáˇr /root. Toto je domovský adresáˇr administrátora systému. Posledním adresáˇrem, který budu popisovat, je /proc, zde najdeme

12

oˇcíslované adresáˇre. Každé cˇ íslo odpovídá jednomu procesu (spuštˇenému programu) a uvnitˇr najdeme informace o spuštˇeném procesu.

Obrázek 1: GNU/Linuxový ko°enový systém

2.8

Red Hat Enterprise Linux

V této kapitole [4] se zamˇeˇrím na konkrétní operaˇcní systém Red Hat Enterprise Linux a jeho odnož Fedora Core. Red Hat Enterprise Linux je významnou komerˇcní GNU/Linuxovou distribucí. Za touto distribucí stojí firma Red Hat. Název Red Hat vznikl díky cˇ ervené buˇrince, kterou majitel spoleˇcnosti Marc Swing dostal od svého dˇedeˇcka a kterou tak rád nosíval, než ji ztratil. Red Hat [5] v minulosti poskytovala i volnˇe šíˇrenou distribuci Red Hat Linux, kterou ovšem v roce 2003 opustila a soustˇredila se na komerˇcní variantu. Samozˇrejmˇe, že všechny zdrojové kódy jsou stejnˇe jako u každého GNU/Linuxu šíˇreny pod licencí GNU GPL a lze je volnˇe stáhnout ze server˚u Red Hatu. Placená je výše zmínˇená podpora. Cena se pohybuje podle konkrétní varianty od nˇekolika tisíc až po statisíce roˇcnˇe. D˚uvodem, proˇc jsou firmy ochotny platit za GNU/Linux, pˇrestože jinou distribuci mohou provozovat zdarma,

13

jsou právˇe záruky od výrobce, který svým jménem ruˇcí za vady produktu a garantuje technickou podporu a vˇcasné opravy chyb. V souˇcasné dobˇe Red Hat sponzoruje komunitní projekt Fedora, vyvíjející distribuci Fedora Core. Ta do znaˇcné míry pˇrevzala jak uživatelskou základnu p˚uvodního Red Hat Linuxu, tak i jeho pozici testovací platformy pro aktualizace Red Hat Enterprise Linuxu. Proˇc firma vytváˇrí komerˇcní a open source systém? Je to jednoduché, open source systém používají obyˇcejní lidé, testují jej a dávají k nˇemu pˇripomínky. Právˇe toto vede k opravení chyb a dosažení stability. Red Hat vychází právˇe z této stability, pˇridá k ní nˇeco navíc, know how, a použije to v distribuci Red Hat Enterprise Linux. Zlí jazykové tvrdí, že uživatelé Fedory jsou beta testery pro vývoj Red Hat Enterprise Linux. Dalším d˚uvodem, proˇc použít komerˇcní systém, je systém certifikát˚u o kompatibilitˇe. Ty si navzájem vydávají výrobci softwaru a hardwaru aby zaruˇcili, že certifikovaný software bezproblémovˇe pobˇeží na certifikovaném operaˇcním systému, nebo že certifikovaný operaˇcní systém bezproblémovˇe pobˇeží na certifikovaném hardwaru, a také že uživatel m˚uže se svým softwarem a operaˇcním systémem pˇrejít na jinou (tˇreba výkonnˇejší) certifikovanou hardwarovou platformu a podobnˇe. Takové „jistoty“ ve svˇetˇe GNU/Linuxu zatím nejsou úplnou samozˇrejmostí. Jak Fedora, tak Red Hat jsou distribuce znaˇcnˇe univerzální. Fedora se zamˇeˇruje na použití na osobních poˇcítaˇcích. Red Hat se oproti tomu zamˇerˇil na zjednodušení serverové správy. Toto zjednodušení pˇrináší nejen lepší správu balíˇck˚u, ale také monitoring vytíženosti a stavu serveru.

Hardwarové nároky Fedory Tato univerzálnˇe použitelná linuxová distribuce [6], vhodná i pro zaˇcínající uživatele, je dostupná zdarma pro všechny hlavní platformy: x86 (PC), x86_64 (AMD64), PowerPC (Mac). Toto jsou minimální hardwarové nároky Fedory Core verze 7: 1. Procesor • Minimum: Pentium-class procesor • Doporuˇceno pro textový mód: 200 MHz Pentium nebo lepší • Doporuˇceno pro grafické prostˇredí: 400 MHz Pentium II nebo lepší 2. Pevný disk a) Pro 32 bit x86 systémy:

14

• Minimální instalace: 620 MB • Server: 1.1 GB • Desktop: 2.3 GB • Pracovní stanice: 3.0 GB • Vše: 6.9 GB b) Pro 64 bit x86_64 systémy: • Minimální instalace: 900 MB • Server: 1.5 GB • Desktop: 2.7 GB • Workstation: 3.4 GB • Vše: 7.5 GB 3. Pamˇet’ a) Pro 32 bit x86 systémy: • Minimum pro textový-mód: 64 MB • Minimum pro grafické prostˇredí: 192 MB • Doporuˇcené pro grafické prostˇredí: 256 MB b) Pro 64 bit x86_64 systémy: • Minimum pro textový-mód: 128 MB • Minimum pro grafické prostˇredí: 256 MB • Doporuˇcené pro grafické prostˇredí: 512 MB Podobnˇe je na tom s hardwarovými nároky vˇetšina GNU/Linuxových distribucí. Takovéto nároky splní vˇetšina výpoˇcetní techniky v nemocniˇcních institucích. Toto však nebyl úˇcel zd˚uraznit, mˇelo to jen ukázat i jiné možnosti využití staršího hardwaru, který již „nestaˇcí“ na MS Windows. 2.9

Live distribuce Slax

Jedná se o „živý“ operaˇcní systém GNU/Linux, který lze spustit z CD, Flash. GNU/Linux Slax [7] vychází z distribuce Slackware. V základním iso souboru je v podstatˇe kompletní

15

window manager4 (správce grafické plochy) KDE. To znamená, že obsahuje základní programy pro používání a správu GNU/Linuxu. Další programy (soubory program˚u) jsou dostupné ve formˇe modul˚u, které si uživatel m˚uže jak vytvoˇrit, tak i stáhnout z domovské stránky Slaxu (http://www.slax.org).

Moduly Moduly jsou zkomprimované programy s koncovkou LZMA. Takto vytvoˇrený modul má v sobˇe adresáˇrovou strukturu, pˇri jehož zavedení do systému se pouze rozbalí do existující adresáˇrové struktury.

Vytvá°ení vlastního modulu Pakliže si nevybereme z pˇredem pˇripravených modul˚u, m˚užeme postupovat nˇekterou z tˇechto možností: 1. Stáhneme si požadovaný program v balíˇcku *.tgz. Následujícím pˇríkazem jej pˇrevedeme na modul pro Slax. tgz2lzm balíˇcek.tgz modul.lzm 2. Jestliže chceme upravit balíˇcek Slackware pˇred vytvoˇrením modulu, použijeme tento postup: • Vytvoˇríme napˇríklad adresáˇr aaaa v adresáˇri /tmp mkdir /tmp/aaaa • Nainstalujeme balíˇcek do souboru /tmp/aaaa jako root systému installpkg -root /tmp/aaaa balíˇcek.tgz • V tomto adresáˇri m˚užeme balíˇcek upravit a poté adresáˇr pˇrevedeme na modul dir2lzm /tmp/aaaa modul.lzm 3. Chceme-li upravit již existující modul, budeme postupovat takto: • Vytvoˇríme napˇríklad adresáˇr 4 Window manager je program, který komunikuje s grackým servrem (X serverem). Window manager spravuje okna a vytvá°í user friendly uºivatelské prost°edí. Gracký server tvo°í prost°edníka mezi jádrem (dostává informace z my²i, klávesnice a posílá výstup na monitor).

16

mkdir /tmp/aaaa • Následujícím pˇríkazem rozbalíme obsah modulu Slaxu do adresáˇre v /tmp/aaaa: lzm2dir modul.lzm /tmp/aaaa • V tomto adresáˇri již m˚užeme modul upravit a opˇet ho pˇrevést na modul dir2lzm /tmp/aaaa modul.lzm Takto vytvoˇrené moduly m˚užeme zahrnout pˇrímo do bootovacího CD (Flash), nebo je pˇridat za bˇehu Slaxu. Jak toto udˇelat, je uvedeno v následující kapitole.

Zavád¥ní modul· I zde existuje nˇekolik možností, kdy zavést modul. Potˇrebujeme-li modul cˇ asto, respektivˇe pˇri každém startu poˇcítaˇce, musíme jej umístit na bootovací médium do adresáˇre /slax/modules/. Tyto moduly jsou vždy zavedeny automaticky pˇri startu. Když potˇrebujeme zavést modul jen obˇcas, umístíme jej na médium a pˇri startu nebo za bˇehu systému, jej zavedeme. Abychom mohli pˇri startu Slaxu zavést modul, musíme zadat parametr load, takže spuštˇení vypadá takto: slax load=jmenomodulu,graphics (doporuˇcuje se, aby takto zavádˇené moduly byly v adresáˇri /slax/optional/ nebo v jeho podadresáˇrích). Pˇridání modulu za bˇehu systému, at’ už z lokálního zdroje (souˇcást iso souboru) nebo z externího zdroje (Flashdisk, internet, CD-ROM, sít’) provedeme pˇríkazem activate. Syntaxe pˇríkazu bude vypadat takto: activate /cesta/k/modulu.lzm. Samozˇrejmˇe zavedené moduly musí jít také odebrat za bˇehu systému. K tomu odstranˇení slouží pˇríkaz deactivate. Tento pˇríkaz má syntaxi napˇríklad deactivate firefox.lzm. V dnešní dobˇe existuje již grafická nadstavba modul˚u, která je umí jednoduše pˇridávat a zase odebírat.

Úprava staºeného iso souboru Slax Nejprve pˇripojíme stažený iso soubor napˇr. do adresáˇre /mnt/iso tímto pˇríkazem: mount -o loop /kde/mame/stazeno/iso.iso /mnt/iso. Protože adresáˇr /mnt/iso je pouze pro cˇ tení musíme obsah tohoto adresáˇre zkopírovat napˇríklad do /tmp/slax (cp -Rv /mnt/iso/* /tmp/slax), kde dokonˇcíme úpravy. Po skonˇcení úprav je potˇreba vytvoˇrit novˇe upravené iso pˇríkazem make_iso.sh.

17

Tlustý klient

Tenký klient

Uºivatelé mají plnohodnotná PC

Uºivatelé mají tenké terminály

Server poskytuje dopl¬kové sluºby

Terminál: displej, klávesnice, my²

Aplikace b¥ºí na PC

Aplikace b¥ºí na serveru

+ + +

+ + + + − − −

− − −

distribuovaný výkon

∗ není Single point of Failure individuální kongurace PC vysoké náklady na po°ízení HW vysoké náklady na servis HW vysoké náklady na správu

nízké náklady na provoz (green IT)

∗

snadná a centrální správa vysoká bezpe£nost p°enositelnost session vhodné pro homogenní pracovní prost°edí vysoké nároky na výkon server· potenciální Single point of Failure

∗

Ukázkové °e²ení server·

Ukázkové °e²ení klient·

farma terminál server·

DELL OptiPlex 755 Ultra Small Factor

2 CPU, 4GB RAM, 2x disk v RAID

WYSE klient

cca 1525 uºivatel· na server ∗ ∗ rad¥ji scale out neº scale up

recyklace starých PC MS Windows, GNU/Linux

Tabulka 1: Porovnání tenkého a tlustého klienta ∗

2.10

je vysv¥tleno v následujícím textu

Výhody a vyuºití Slaxu

Výhodou bylo to, že jsem si stáhnul a nainstaloval Slackware na sv˚uj poˇcítaˇc. Na nˇem jsem pˇrímo testoval a poté jsem použil ty samé konfigurace pro Slax. Další výhodou byla jeho jednoduchá modularita. Slax LiveCD verze 6.0.6 jsem stáhl z jeho domovské stránky. Tuto základní konfiguraci jsem nakonec doplnil o modul modul_honza, který zavádí do systému jak klávesovou mapu cz-cp1250-clinicom.map.gz, tak skript, pro pˇripojení k NIS Clinicom pˇres ssh. Více o realizaci pojednává kapitola 8. 2.11

Tenký klient

Tato kapitola [8] bude spíše o porovnání „tenkých“ a „tlustých“ klient˚u. Nejprve si však musíme rˇíci, co je to tenký a tlustý klient. Tenký klient je poˇcítaˇc, který se pˇri spuštˇení pˇripojí k serveru a pouští na nˇem potˇrebné aplikace. Klient tudíž slouží jen pro zobrazení toho, co mu posílá server (zobrazuje jeho plochu). Každý takto pˇripojený poˇcítaˇc, respektive pˇrihlášený uživatel, má sv˚uj vlastní profil, tak jako je tomu na klasickém desktopovém poˇcítaˇci. Tlustý klient je pravý opak, aplikace bˇeží na stolním poˇcítaˇci a server poskytuje doplˇnkové služby. Tyto a ještˇe další skuteˇcnosti zobrazuje tabulka 1.

18

Green IT Tenký klient pouze zobrazuje informace ze serveru, proto jeho spotˇreba je mnohem nižší než u stolního poˇcítaˇce. Je-li klient ˇrešen napˇríklad tenkým klientem od firmy WYSE má ˇ spotˇrebu cca 5,6 watt˚u. Oproti tomu stolní poˇcítaˇc má spotˇrebu cca 180 W. Cásteˇ cný výpis této poˇcítaˇcové sestavy je uveden v tabulce 2. CPU

Intel Core 2 Duo E6300-tray OEM (1,86 GHz)

RAM

512 MB DDR2-667 MHz Kingston CL5

Zdroj

Fortron 350W/LN/12fan/PFC/P4/24PIN,FSP350-60THN-P

HDD

250GB Seagate B-7200.10 16MB SATAII/300 7200r Tabulka 2: Po£íta£ová sestava NIS Clinicom

Homogenní prost°edí Vˇetšina uživatel˚u využívá poˇcítaˇc k podobné cˇ innosti. Jedná se napˇríklad o pˇrístup k nemocniˇcnímu informaˇcnímu serveru, prohlížení obrazové dokumentace a používání kanceláˇrských program˚u, jako tomu je na vˇetšinˇe nemocniˇcních oddˇelení, kdy sestry a lékaˇri vˇetšinou nepotˇrebují nic jiného pro svou práci. Samozˇrejmˇe kromˇe specializovaných pracovišt’. Takovýmto pracovištˇem je napˇríklad rentgen, kdy lékaˇr potˇrebuje obsluhovat pomocí poˇcítaˇce i rentgen, pˇrípadnˇe získané obrázky upravovat a ukládat.

Náklady a centrální správa Tenký klient výraznˇe snižuje náklady, zejména v oblasti administrace a servisu. V pˇrípadˇe nasazení GNU/Linuxu na severy jsou ještˇe náklady sníženy o náklady na licence. Když uživatel nˇeco zmˇení, tak vždy pˇri dalším nastartování tenkého klienta, je vše v p˚uvodním stavu. Proto takˇrka odpadá následná správa, jako u stolních poˇcítaˇcu˚ .

Single point of Failure Jedná se o závadu jednoho bodu v cestˇe mezi serverem a klientem. Klienti pˇripojení za tímto bodem jsou nefunkˇcní.

Scale out Scale out je typ rozšiˇrování (zvyšování) serverové výkonosti, kdy se nerozšiˇruje pamˇet’, ani se nepˇridávají procesory, ale instalují se další servery. Výše zmínˇený server je vybrán právˇe takto, protože takovéto servery mají nejoptimálnˇejší pomˇer cena/výkon.

19

2.12

Jak funguje tenký klient

Všechny možnosti realizace tenkého klienta jsou témˇeˇr stejné. Jednotlivé realizace se mohou lišit at’ už cestami k soubor˚um, názvy soubor˚u, nebo spouštˇeným operaˇcním systémem. Nyní v krátkosti popíši realizaci tenkého klienta projektem LTSP (Linux Terminál Server Projekt) [9]. Pro tenkého klienta je nutné nejprve pˇripravit operaˇcní systém, který bude zaveden do terminálu, programy a jádro. Dále se musí na serveru nakonfigurovat DHCP server, TFTP (Trivial File Transfer Protokol) a NFS (Network File System). V dnešní dobˇe existují firmy, které se živí realizací tenkých klient˚u. Tyto firmy mají pro tenké klienty pˇripraveny své operaˇcní systémy. Oproti tomu existuje napˇríklad projekt LTSP, který má pˇripraven také vlastní typ operaˇcního systému a konfiguraˇcní skripty pro snadnˇejší realizaci tenkého klienta. Nyní se dostáváme k tomu, jak probíhá start tenkého klienta. Pˇri startu poˇcítaˇce vyšle Etherboot kód se žádostí o pˇridˇelení IP adresy DHCP serverem. Žádost obsahuje MAC adresu sít’ové karty. DHCP démon bežící na serveru zachytí vyslanou žádost z pracovní stanice a ve svém konfiguraˇcním souboru vyhledá záznam, kterému odpovídá MAC adresa stanice, která žádost vyslala. DHCP démon vytvoˇrí jako odpovˇed’ paket, který obsahuje tyto informace: • IP adresu pro pracovní stanici • NETMASK - sít’ovou masku - pro tuto lokální sít’ • Cestu s uložením jádra pro stažení • Cestu ke koˇrenovému adresáˇri souborového systému pro pˇripojení • Nepovinné parametry, které mají být pˇredány jádru pˇres pˇríkazový ˇrádek Etherboot pˇrijme odpovˇed’ ze serveru a nakonfiguruje TCP/IP rozhraní na sít’ové kartˇe s parametry, které byly dodány. Poté použije TFTP (Trivial File Transfer Protocol) a zaˇcne stahovat jádro. Po úspˇešném stažení jádra na pracovní stanici, Etherboot umístí jádro na správné místo do pamˇeti. Nejprve probˇehne kontrola jádra, inicializuje se celý systém, všechna periferní zaˇrízení, která nalezne, a na konec zavede obraz souborového systému do pamˇeti jako RAM (randomaccess memory = pamˇet’ s libovolným (náhodným) pˇrístupem) disku. U desktopu, když jádro ukonˇcuje zavádˇení, spustí program init. V tomto pˇrípadˇe se instruovalo jádro, aby zavolalo speciální shell skript (init=/linuxrc). Skript /linuxrc zaˇcne skenovat PCI sbˇernici, hledá sít’ovou kartu a dostupný hardware.

20

Úrove¬ 0

Zavolá procesy nezbytné pro zastavení systému

Úrove¬ 1

Spustí textovou konzoli v jednouºivatelském reºimu

Úrove¬ 2

Spustí textovou konzoli v lokálním víceuºivatelském reºimu bez p°ístupu do sít¥

Úrove¬ 3

Spustí textovou konzoli ve víceuºivatelském reºimu s p°ístupem do sít¥

Úrove¬ 4

Nebývá vyuºitá

Úrove¬ 5

Spustí víceuºivatelský reºim s p°ístupem do sít¥ a grackým p°ihla²ovacím rozhraním

Úrove¬ 6

Zavolá procesy nezbytné pro restart systému Tabulka 3: Úrovn¥ mód· v GNU/Linux

Po identifikaci sít’ové karty skript /linuxrc zavede modul jádra, který podporuje tuto kartu. Poté je spuštˇena aplikace dhclient, která nastaví sít’ovou kartu pro pˇríjem adresy od DHCP serveru. Když dostane dhclient odpovˇed’ ze serveru, spustí se soubor /etc/dhclientscript, který podle získaných informací nakonfiguruje rozhraní eth0. Do tohoto bodu byl koˇrenovým souborovým systémem RAM disk. Nyní, skript /linuxrc pˇripojí nový koˇrenový souborový systém pomocí NFS(Network File System). Tento „nový“ koˇrenový souborový systém, tenkého klienta je vˇetšinou v /opt/ltsp/i386. Není možné jej ihned pˇripojit jako nový souborový systém /. Nejprve se pˇripojí do /mnt. Po dokonˇcení je NFS souborový systém pˇripojen jako / a starý koˇrenový adresáˇr je pˇripojen jako /oldroot. V tuto chvíli máme již zaveden operaˇcní systém a jen zbývá, aby se spustila požadovaná úroveˇn módu (run levell) [10], ve kterém GNU/Linux pobˇeží. Tˇechto mód˚u je 7(viz tabulka 3), ale pro tento pˇrípad budou staˇcit dva a to úroveˇn 3 a 5.

3

Informa£ní systémy

Nemocniˇcní informaˇcní systém (NIS) [11] pokrývá veškeré zpracování informací v rámci nemocnice. Pro sv˚uj rozsah je cˇ lenˇen na nˇekolik cˇ ástí, které mezi sebou vzájemnˇe spolupracují. Charakteristickými rysy je decentralizace poˇrizování a zpracování dat a zároveˇn centralizace pozornosti na nemocného, která se vyjadˇruje termínem „patient oriented“. Dˇrívˇejší vedení papírové dokumentace neumožˇnovalo shromáždit všechna data týkající se pacienta do jednotného systému. Údaje o ambulantním ošetˇrení byly v kartotéce ambulance, údaje o hospitalizaci byly v archivu l˚užkového oddˇelení apodobnˇe. Tak bylo obtížné soustˇredit, v pˇrípadˇe potˇreby, všechny informace o pacientovi. Integrujícím prvkem je kom-

21

patibilita dat, která umožˇnuje komunikaci mezi jednotkami uvnitˇr NIS i vazbu na vnˇejší struktury. 3.1

Historický p°ehled uplatn¥ní po£íta£· v medicín¥

Pojem uplatnˇení výpoˇcetní tecniky se objevil kolem roku 1960. Jedním z prvních, kdo upozornil na jeho d˚uležitost byl Langerors. V roce 1966 vydal knihu „Teoretická analýza informaˇcních systém˚u“, která se stala základem uznávané skandinávské školy. Tato publikace obsahuje popis systémového pˇrístupu ke sbˇeru, zpracování a využívání údaj˚u za úˇcelem získávání informací. V historii vývoje zdravotnických informaˇcních systém˚u ve svˇetˇe m˚užeme rozeznat nˇekolik charakteristických etap.

1960 1970: osamocené dávkové aplikace V tomto období se zaˇcaly objevovat první systémy orientované na samostatné dílˇcí oblasti nemocnice, jako jsou registry pacient˚u a kartotéky údaj˚u. Charakteristickým rysem bylo dávkové zpracovávání pomocí dˇerných štítk˚u a z toho vyplývající znaˇcná cˇ asová prodleva mezi sbˇerem dat a výsledkem jejich zpracování. První implementací v USA byl informaˇcní systém v kalifornském Sunnyvale v nemocnici El Camino Hospital, který vznikl za spolupráce s firmou Lockheed v roce 1967.

1970 1975: subsystémy S postupným vývojem technických a programových nástroj˚u byly vytváˇreny aplikace ˇrešící funkˇcní celky v rámci nemocnice. Typickým pˇríkladem byly napˇr. laboratorní subsystémy LIS. Takto pokryté celky se však cˇ asto funkˇcnˇe pˇrekrývaly, což vedlo k redundanci zpracovávaných údaj˚u. Jednou z prvních implementací ambulantního systému byl COSTAR (Computer Stored Ambulatory Record), který byl vyvíjen od konce šedesátých let v Massachusetts General Hospital. Byl provozován v ambulantním zaˇrízení poliklinického typu, které dennˇe zaznamenalo kolem 550 ošetˇrených pacient˚u. Jeho další verze obsahovala po roce 1978 i funkce pro úˇctování výkon˚u. V první polovinˇe sedmdesátých let mají p˚uvod i nejstarší evropské informaˇcní systémy nemocnic ve Vídni a v Ženevˇe, které vznikly jako menší databanky pro evidenci nemocných a postupnˇe se rozvinuly v plnohodnotné informaˇcní systémy.

22

1975 1980: snaha o totální informa£ní systém Snahou vyhnout se redundanci pˇri zpracování dat je možné vysvˇetlit tendenci, která vznikla v tomto období – vytvoˇrit integrovaný informaˇcní systém v rozsahu celé nemocnice, který byl cˇ asto oznaˇcovaný jako „totální nemocniˇcní informaˇcní systém“. Všechny snahy o vytvoˇrení takového systému byly však jak v USA, tak v Japonsku a dalších vyspˇelých zemích neúspˇešné. D˚uvodem selhání byly dvˇe zásadní skuteˇcnosti: 1. Nedostateˇcný technický výkon poˇcítaˇcu˚ . Malá operaˇcní rychlost, nedostateˇcná kapacita vnitˇrních i vnˇejších pamˇetí a malý poˇcet pˇripojitelných terminál˚u. 2. Podcenˇení složitosti úlohy. Zdravotnická zaˇrízení pˇredstavují organizaˇcní strukturu s komplikovanými vnitˇrními vazbami, kde se cˇ asto mˇení a vyvíjejí jak jednotlivé složky systému, tak vazby mezi nimi.

1980 1990: roz²í°ení dob°e zvládnutých aplikací Nezdar komplexního ˇrešení v pˇredchozích letech vedl ke snaze vrátit se k ˇrešení ucelených subsystém˚u v rámci nemocnice, ale již na kvalitativnˇe a zejména metodologicky vyšší úrovni. Byl pˇresnˇe specifikován obsah a rozsah jednotlivých subsystém˚u a definovány jejich vzájemné vztahy a vazby. Systémy byly již koncipovány pro budoucí propojení do komplexního informaˇcního systému. V tomto období byly definovány spoleˇcné databáze pacient˚u sdílenými jednotlivými subsystémy. Byly provedeny první projekty jednotné identifikace pacient˚u, struktury archivovaných údaj˚u, formalizace medicínských dat a informací. Metodiky zpracování informaˇcního systému se od snahy vytvoˇrit všeobecnˇe použitelný program zmˇenily ve prospˇech systému co nejlépe vyhovujícímu konkrétním podmínkám zdravotnického pracovištˇe. Informaˇcní systém ve Všeobecné univerzitní nemocnici ve Vídni v této dobˇe obsahoval již administrativní moduly zpracovávající pˇredevším identifikaˇcní a základní klinické údaje o pacientech a statistiku pro potˇreby ˇrízení nemocnice, klinický modul, který slouží jako podp˚urná funkce pro diagnostickou a léˇcebnou cˇ innost a hospodáˇrský a technický modul, který má za úkol pomáhat pˇri rˇízení provozu nemocnice vˇcetnˇe ovládání technologie budov (klimatizace, požární systém), zásobování léky a materiálem. Informaˇcní systém Univerzitní nemocnice v Ženevˇe již v roce 1988 rutinnˇe používal osobních karet s magnetickým a mechanickým záznamem pro identifikaci pacient˚u na l˚užkových oddˇeleních, v laboratoˇrích a dalších provozech.

90. léta dvacátého století: totální informa£ní systém Poˇcítaˇce jsou vybaveny dostatkem vnitˇrní pamˇeti a periferní pamˇeti doznaly nevídaného nár˚ustu. V d˚usledku toho vede rychlost odezvy poˇcítaˇcu˚ spolu s rozvojem poˇcítaˇcových sítí

23

k zlepšení možnosti úplného informaˇcního systému nemocnic. Lze konstatovat, že nikde na svˇetˇe nebyla dosud ohlášena realizace „totálního nemocniˇcního informaˇcního systému“. Pˇri uvážení, že k jeho realizaci je tˇreba nejdˇríve definovat úˇcelné prvky z množiny všech dˇej˚u, pak lze odvodit, že nikdo doposud tuto rozumnou podmnožinu nedefinoval, nebo-li – úspˇešné nemocniˇcní informaˇcní systémy, které sami sebe jako totální nedefinují, jimi vlastnˇe jsou.

po roce 2000 - miniaturizace Od roku 2000 [12] jsou již pokusy s uplatnˇením PDA (personal digital assistant = osobní digitální pomocník). Zkoumá se myšlenka, že jej lékaˇr používá bˇehem vizity nebo je pˇrímo zapojený v IS u l˚užka pacienta. Další možností minimalizace je zapojení mobil˚u do proces˚u objednávání a informování prostˇrednictvím SMS zpráv. Poslední možností je komunikace s NIS pˇres Internet 3.2

Vyuºití výpo£etní techniky ve zdravotnictví

Cíle procesu aplikace výpoˇcetní techniky do zdravotnictví: • Zlepšení úrovnˇe ˇrízení a organizace cˇ inností • Zvýšení rychlostí a spolehlivosti pˇrístupu k informacím • Rozšíˇrení rozsahu informací nutných pro rozhodování a ˇrízení • Lepší a snazší modelování a simulace

možnost libovolnˇe opakovat experiment možnost mˇenit vstupní data a podmínky experimentu - simulace extrémních situací

možnost mˇenit cˇ asové mˇeˇrítko a studovat dˇeje extrémnˇe rychlé i pomalé možnost rozšiˇrovat a upˇresˇnovat model dle potˇreby bez vˇetších náklad˚u a rizik vstupní veliˇciny: cˇ ísla, kódy, signál, . . . výstupní veliˇciny: numerické hodnoty, grafy, . . . Další možnost využití výpoˇcetní techniky, jsou v diagnostických a terapeutických systémech. Hlavní pˇrínos je ve zdokonalení a rozšíˇrení funkcí pˇrístroj˚u, výkonnosti, spolehlivosti. Samozˇrejmˇe také ve zvýšení komfortu obsluhy. Nejd˚uležitˇejší byla unifikace výstupu a zajištˇení pˇrímého propojení s jinými poˇcítaˇci nebo pˇrístroji. V tuto chvíli vznikly revoluˇcní

24

metody u vyšetˇrovacích technik (CT, MR, UZV, . . . ), kde již obsluha nemusí být odborník na výpoˇcetní techniku. Oblasti pˇrístrojové techniky, kde se výpoˇcetní technika využívá, jsou monitoring, funkˇcní fyziologická vyšetˇrení, RDG a UZV, podp˚urné a terapeutické systémy, laboratorní automaty, atd.. 3.3

Informa£ní systémy

Informaˇcní systémy (IS) vystihuje jedna z definic takto: Je to soubor technických a programových prostˇredk˚u umožˇnujících aplikaci automatizovaného zpracování informací. Hlavními úlohami IS ve zdravotnictví je získávání, uchovávání, pˇrenos a zpracovávání velkého množství informací. Rozeznáváme tyto základní typy zdravotnických IS. • Celostátní a nadnárodní • Regionální • Nemocniˇcní • Klinické • Lokální a specializované

Celostátní IS Jsou to IS organizaˇcnˇe a ekonomicky velice nároˇcné. Zajišt’ují sbˇer a zpracování informací z celého území státu.

Regionální IS Tyto IS nejsou již tak organizaˇcnˇe a ekonomicky nároˇcné jako celostátní, ale pˇresto jejich realizace je velice nároˇcná. Souˇcástí tˇechto IS jsou demografické informace (registry obyvatelstva). Dále pak sledují poˇcet a nároˇcnost výkon˚u zdravotnických zaˇrízení, celkový poˇcet a strukturu onemocnˇení, financování zdravotnictví.

25

Nemocni£ní IS Nejprve si musíme definovat, jaké jsou a co zahrnují dva nejd˚uležitˇejší provozy v nemocnicích. Prvním je ekonomická cˇ ást, která obsahuje napˇríklad osobní oddˇelení, finanˇcní a mzdovou úˇctárnu, oddˇelení úˇctování zdravotním pojišt’ovnám, lékárnu, sklad zdravotního a pomocného materiálu, oddˇelení pro potraviny, investice a jejich plánování, inventarizaˇcní oddˇelení, zdravotnické zásobování, pˇrístrojové vybavení, správu budov, kuchyni, údržbu, dopravu. Druhou cˇ ástí je léˇcebná cˇ ást, která zahrnuje l˚užková oddˇelení, ambulance, centrální pˇríjem pacient˚u, operaˇcní sály, rehabilitace, laboratoˇre, radiodiagnostika, patologie, transfúzní stanice a záchrannou službu. Nemocniˇcní systém není jeden systém, ale tvoˇrí jej skupina vzájemnˇe spolupracujících subsystém˚u. Jednotlivé informaˇcní subsystémy zajišt’ují sbˇer a zpracování medicínských a hospodáˇrsko-správních informací. Více informací je v kapitole 4.

Klinický IS (KIS) Tyto informaˇcní systémy mají stejný základ. Tím je pacientsky orientovaná databáze (DB), která obsahuje veškeré informace dˇríve uchovávané v klinické dokumentaci. Pacientská DB má podle obor˚u pr˚umˇernˇe 10-20 kB cˇ isté informace na pacienta a hospitalizaci. Uplatnˇením KIS dochází ke zpˇresnˇení a zkvalitnˇení diagnosticko-terapeutického procesu a jeho zabezpeˇcení. Pacientská data tvoˇrí kvalitativnˇe novou bázi informací pro klinický výzkum a ovˇeˇrování nových postup˚u. KIS bývají cˇ asto realizovány jako lokální subsystémy NIS, technicky jako LAN s personálními poˇcítaˇci ˇ Rešení lokálních problém˚u je nutné cˇ asto realizovat dílˇcími IS bez ohledu na dosud nerealizovaný celkový zámˇer. Vznikají tak lokální (specializované) IS. V praxi jsou to cˇ asto tyto cˇ ásti: • IS biochemické nebo hematologické laboratoˇre • IS transfúzní stanice • IS mikrobiologické laboratoˇre • IS JIP • IS radiodiagnostického oddˇelení • IS oddˇelení radiaˇcní terapie

26

Lokální a specializované IS IS v ambulantní péˇci (AIS) Jeho úˇcelem je poskytnout lékaˇri prostˇredky pro snadné a úˇcelné vedení záznamu ve zdravotnické dokumentaci pacient˚u. Dˇelí se z hlediska vazeb na izolované, navzájem propojené a tvoˇrící poliklinický IS, s vazbou na KIS nebo NIS. ˇ IS v lázenství Tyto systémy mají velmi úzkou návaznost na zdravotnictví a jejich specifikem vedle diadgnostiky a léˇcebné funkce je i hotelová a turistická péˇce. 3.4

P°enos informací v IS

Je potˇreba rychlého, spolehlivého a pˇresného pˇrenosu informací v rámci IS. Z toho d˚uvodu se informace uspoˇrádávají do zprávy. Struktura zprávy umožní bezpeˇcný pˇrenos informace uvnitˇr IS ale i mezi oddˇelenými IS. Tˇemto zprávám je umožnˇeno pˇridˇelit prioritu.

4

Nemocni£ní informa£ní systém

Pro NIS definujme množinu spoleˇcných cíl˚u. V nˇekterých speciálních pˇrípadech mohou být informaˇcní potˇreby jednotlivých uživatel˚u mimo rámce tˇechto cíl˚u, ale vˇetšina by mˇela vycházet z tˇechto obecnˇe formulovaných cíl˚u. Pro vybudování kompletního NIS jsou udávány tyto: 1. Zvýšení úrovnˇe diagnostické, léˇcebné a ošetˇrovatelské cˇ innosti 2. Ekonomická efektivnost provozu a podpora ˇrízení na všech úrovních 3. Usnadnˇení administrativních cˇ inností 4. Usnadnˇení provozních cˇ inností 5. Vzájemná komunikace, zkvalitnˇení obˇehu a dostupnosti informací 6. Výzkum 4.1

Pouºívané technologické architektury NIS

Používá se distribuovaná databáze a distribuované zpracování dat. M˚uže-li jedna aplikace prakticky bez kontroly mˇenit data jiné aplikace, existuje velké nebezpeˇcí poškození dat. Z toho d˚uvodu je vytvoˇrena pomocná externí aplikace „skladník“, která m˚uže poskytovat ˇradu služeb, jako jsou pokroˇcilé prostˇredky analýzy dat.

27

Dˇríve byla jedna centrální databáze, která byla fyzicky vedena na sálovém poˇcítaˇci a uživatelé k ní mˇeli pˇrístup pomocí terminál˚u. S rostoucím objemem požadavk˚u na zpracování dat bylo nutné zajistit geografickou dostupnost dat. V dnešní dobˇe toto rˇeší tzv. distribuované databáze. Externí aplikace mohou využívat, a také využívají, distribuovaná úložištˇe na r˚uzných místech sítˇe. S architekturou distribuované databáze velmi úzce souvisí distribuované zpracování dat, které znamená, že se úloha zpracování informací neprovádí na jednom centrálním poˇcítaˇci, ale rozloží se na více poˇcítaˇcu˚ . Ty si pak navzájem „sdˇelují“ výsledky zpracování a „nechají nahlédnout“ okolním poˇcítaˇcu˚ m do výsledk˚u ve své cˇ ásti databáze. 4.2

P°ipo jení k databázím NIS

Kapitola pojednává o možnostech pˇripojení k databázím NIS.

Tenký klient ↔ Server Jde o historicky velmi starý typ technologické architektury. Je charakterizován centrálními poˇcítaˇci, ke kterým je pˇripojeno mnoho tzv. tenkých terminál˚u. S pˇríchodem osobních pocˇ ítaˇcu˚ a jejich grafických prostˇredk˚u se nabídla možnost grafického uživatelského rozhraní (GUI=Graphics User Interface). Musíme však posoudit, zda by nešlo na této variantˇe ušetˇrit. Jedna možnost je již zmiˇnovaný tenký klient (viz kapitola 2.11). Výhodou architektury tenký klient-server je nezávislost na použitém hardware, zacílení na procesy probíhající ve zdravotnickém zaˇrízení více než na vlastní technologie, podstatnˇe zvýšené schopnosti portability, flexibility a možnost interoperability.

Klient ↔ Server S pˇríchodem osobních poˇcítaˇcu˚ a jejich grafických prostˇredk˚u se nabídla možnost grafického uživatelského rozhraní GUI. Zároveˇn se objevila možnost provozovat na osobním poˇcítaˇci i cˇ ást vrstvy logiky aplikace. Aplikace se tak rozdˇelí na dvˇe cˇ ásti, cˇ ást klientskou a cˇ ást bˇežící na výkonném centrálním poˇcítaˇci (serveru cˇ i na síti server˚u). Další podstatnou vlastností architektury klient-server je skuteˇcnost, že informaˇcní systém je vnímán jako služba uživateli, tedy systém bude využíván (jako definovaný proces) pouze, pokud bude uživatel potˇrebovat informaˇcní podporu.

28

4.3

P°ínosy NIS

K nejˇcastˇejším pˇrínos˚um zavedení NIS v nemocnicích patˇrí pˇrenos dat po síti mezi jednotlivými oddˇeleními nemocnice a mezi externími zaˇrízeními. Mezi další funkce, které zvyšují optimalizaci jeho využití, je zefektivnˇení práce zdravotníka s pacientskými daty, kde jsou automaticky opravovány nedostatky a neúplnosti, které by napˇr. mohly vést k nemožnosti vyúˇctování péˇce a finanˇcní ztrátu nemocnice. Jsou zde funkce podporující plánování návštˇev, optimalizaci úˇctování výkon˚u, finanˇcních náklad˚u apod.. 4.4

Nemocni£ní informa£ní systém v eské republice

ˇ V historii zdravotnických informaˇcních systém˚u v Cesku a na Slovensku lze sledovat nˇekolik základních rys˚u a velmi skromné technické vybavení. Pˇred rokem 1989 byla prosazována orientace na techniku výluˇcnˇe z domácích zdroj˚u, a proto s trochou nadsázky lze rˇíct, že projekty 80. let používaly techniku 70. let se spolehlivostí 60. let, což ve vˇetšinˇe realizovaných aplikacích vedlo ke ztrátˇe d˚uvˇery k používání poˇcítaˇcu˚ ve zdravotnictví a k odmítání informaˇcních systém˚u. Opoždˇení po roce 1989 je pˇribližnˇe deset rok˚u. Pˇres toto opoždˇení lze pozorovat podobné etapy vývoje jako v okolním svˇetˇe. Pr˚ukopníkem tvorby nemocniˇcního informaˇcního systému byl Výzkumný ústav traumatologický v Brnˇe a nemocnice v Benešovˇe. Informaˇcní systém praktického lékaˇre rˇešila jako první skupina programátor˚u a lékaˇru˚ v Jindˇrichovˇe Hradci. Výkonný laboratorní subsystém (LIS) byl v provozu v pražské nemocnici na Bulovce. Jak je vidˇet z tabulky 4 [13], v oblasti NIS je zatím ve hˇre pˇrekvapivˇe mnoho firem i produkt˚u a žádný si zatím nedokázal zajistit dominantní postavení na trhu. Z velkých firem si velmi dobré zázemí mezi souˇcasnými i potenciálními zákazníky vytvoˇrilo díky svému laboratornímu systému pardubické STAPRO (v souˇcasné dobˇe „obhospodaˇrující“ drtivou vˇetšinu laboratoˇrí). Ve zvláštním postavení se nalézá firma SMS: ve svˇetovém mˇerˇítku jde o jednoho z nejvˇetších dodavatel˚u NIS, u nás zatím, co do poˇctu instalací, tˇeží ze svých tuzemských akvizic pˇrevzatých od firem Dialog-NIS a Ostrasoft. K tˇemto systém˚um je nutné doplnit produkty firem HIPPO s.r.o. a MEDICON a.s., se kterými se také musí poˇcítat.

29

po£et instalací

rma

ozna£ení NIS

DATA-PLAN Bohemia, s.r.o.

Net WinMed

19

HiComp Systems CZ, s.r.o.

NIS HiComp

25

HIPPO, s.r.o.

ISpP HIPPO

20

ICZ, a.s.

MPA AMIS*H

3

AMIS*H/2000 LOGIS, s.r.o

HERMES

20

1

MEDICALC software, s.r.o.

WinMedical

28

MEDICON, a.s.

GreyFox

5

PCS Systems, s.r.o

PCS*CARE

9

SMS, s r.o.

CLINICOM

32

SMS, s.r.o.

S4M NIS

SoPHIS, a.s.

Pharma X

STAPRO, s.r.o.

StaproMEDEA

STAPRO, s.r.o

StaproAKORD

STEINER

UNIS

87 10

TietoEnator VIP Most, s.r.o

MEDIX

WEBCOM a.s.

Microsoft Dynamics

Tabulka 4: P°ehled rem nabízejících NIS v R (3/2008)

zákazník

konc. st.

po£et l·ºek

Nemocnice eské Bud¥jovice

1020

1700

FN s poliklinikou Ostrava 1994

1300

1400

Masarykova nemocnice Ústí nad Labem 1997

1500

1400

Nemocnice s poliklinikou Ivan£ice 1996

278

300

M¥stská nemocnice s poliklinikou Ostrava 1997

150

1100

Nemocnice ve Svitavách 2001

165

300

Nemocnice Boskovice 2008

84

269

I. Zdravotní Rumburk a.s. 2003

90

200

Tabulka 5: Po£et instalací NIS Clinicom v R (3/2008)

30

5

Clinicom

P˚uvod NIS Clinicom [14] je v SRN. Výhradní zastoupení produktu firmou SMS, s.r.o je na základˇe licenˇcní smlouvy a plnˇe se pˇrizp˚usobilo cˇ eskému prostˇredí. Jedná se o komplexní, robustní, nemocniˇcní informaˇcní systém s nadstavbovými moduly, které umožˇnují optimalizaci proces˚u. Je zde použita postrelaˇcní databáze CACHE firmy InterSystems. ˇ Financování nemocniˇcní péˇce prochází v Ceské republice ˇradou zmˇen. D˚uležitou vlastností NIS je proto nezávislost na budoucím zp˚usobu úˇctování péˇce a plná adaptabilita NIS v daném období na platný zp˚usob financování (výkonový systém, DRG, paušální platby atd.). NIS Clinicom je maximálnˇe nezávislý. Vychází ze zkušeností v USA a zemích EU a je proto snadno pˇrizp˚usobitelný všem typ˚um úˇctování péˇce. NIS Clinicom je koncipován tak, aby byl v maximální míˇre postaven na promˇenných položkách a cˇ íselnících. Pouhým pˇrenastavením hodnot lze potom dosáhnout odlišného chování systému. To oceˇnují uživatelé pˇredevším v pˇrípadˇe zmˇen úˇctování lékaˇrské péˇce. Modulární systém s velkým stupnˇem možností uživatelského pˇrizp˚usobení umožˇnuje snadné propojení s jinými IS zdravotnického zaˇrízení. Pˇreddefinované nastavení standardních komunikaˇcních protokol˚u používaných ve zdravotnictví umožˇnuje snadnou komunikaci s dalšími subjekty a nabízí možnost pˇrímého propojení do národních i nadnárodních zdravotnických sítí a on-line výmˇenu informací. 5.1

Základní pilí°e

Clinicom má 4 základní pilíˇre, díky nimž lze lépe rozvíjet jeho modularitu:

Správa pacient· Centrální správa pacient˚u, která pˇrináší zásadní výhodu v tom, že všechna data jsou zadávána pouze jedenkrát.

Správa výkon· Ta zajišt’uje rutinní chod nezávisle na personálu, uživatelé pouze vkládají uskuteˇcnˇené výkony, zatímco systém se stará o správný chod v souladu s legislativou a metodikou.

Komunikace NIS komunikace vystavováním žádanek, jejich odesláním a pˇríjmem výsledk˚u s nastavitelnou úrovní rozlišení.

31

Správa operací Toto je úˇcinný nástroj pro sledování zákrok˚u a operací za úˇcelem získání pˇresných údaj˚u o nákladech a výnosech. Dále nepˇredstavuje jen administrativní nástroj lékaˇre pro usnadnˇení poˇrízení a archivace povinné dokumentace, ale je také navržen ke sledování ekonomiky nemocnice. Data z NIS lze dále zpracovat a vyhodnotit prostˇrednictvím manažerského informaˇcního systému DSS (Decision Support System). 5.2

Specializované moduly systému

NIS Clinicom je rozvíjen v souladu s požadavky uživatel˚u. V souˇcasné dobˇe disponuje vedle jádra systému tˇemito pˇrídavnými moduly: • Modul CC Porodnice • Modul CC OptimDRG • Modul CC Rehabilitace • Modul CC JIP • Modul CC Ošetˇrovatelská péˇce • Modul CC Protokoly péˇce • Modul CC Medikace • Modul MemoMXS5 5.3

Uºivatelská rozhraní systému

V dnešní dobˇe je trend, využívat GUI. Proto se touto cestou vydává i NIS Clinicom. Nemˇelo by se však zapomínat na starší, ale stále funkˇcní, terminálový pˇrístup.

Textový terminál Terminál je poˇcítaˇc, který pouze vysílá, pˇrijímá a zobrazuje znaky dle urˇcitých konvencí. Nemá s konkrétní aplikací nic spoleˇcného, protože tato aplikace bˇeží na serveru. Terminál˚u 5 Aplikace memoMXS umoº¬uje ukládání informací o transakcích mezi klientem a serverovou £ástí NIS CLINICOM. V t¥chto informacích je moºné nadále vyhledávat a t°ídit je tak, aby bylo jednodu²²í a rychlej²í zjistit, který uºivatel a kdy zapisoval údaje, ale také kdy, kdo a jaké údaje £etl.

32

se využívalo pˇredevším dˇríve, byly to pouze pracovištˇe s klávesnicí, monitorem a málo výkonným poˇcítaˇcem. Textový terminál m˚uže být ale realizován programem ve Windows (Putty, KoalaTerm, ArcTel, ...) nebo GNU/Linux (napˇríklad konsole, gnome-terminal - souˇcást GNU/Linuxových distribucí).

CareCenter Care Center je grafické uživatelské rozhraní systému Clinicom, realizované pro prostˇredí Windows. Care Center zprostˇredkovává okamžitý pˇrístup k žádankám, nález˚um, lékaˇrské dokumentaci a k informacím o protokolech. Tento produkt poskytuje uživateli jednoduchý pohled na informace o zvoleném pacientovi. Dále vidí informace o pohybu a stavu pacienta od jeho pˇrijetí až po ukonˇcení léˇcby.

NetAccess NetAccess je jednoduchý zabezpeˇcený pˇrístup k lékaˇrským informacím prostˇrednictvím Internetu (Intranetu). Slouží k zadávání požadavk˚u a zobrazení vybraných údaj˚u. Pracuje se stejnou množinou dat jak Care Center a uživateli nabízí také velmi podobné grafické rozhraní. Samozˇrejmostí je plná podpora nejrozšíˇrenˇejších prohlížeˇcu˚ . NetAccess je aplikace klient - server, což pˇrináší minimalizaci na zˇrízení a údržbu koncového zaˇrízení tenkého klienta. NetAccess využívá standard SSL pro zabezpeˇcené spojení. 5.4

Databázová platforma CACHE

Databázové prostˇredí nemocniˇcního informaˇcního systému SMS je založeno na postrelaˇcní objektové databázi CACHE americké firmy InterSystems. Je významným svˇetovým dodavatelem databázových technologií v oblasti zdravotnictví. Databáze CACHE ukládá data do vícerozmˇerného datového modelu, což umožˇnuje efektivní popis dat. CACHE nabízí vysoký výkon pˇri zpracování komplexních transakcí (je až 20x výkonnˇejší než srovnatelné standardní relaˇcní databáze). Databáze CACHE byla pˇredstavena v roce 1997. Je nejen vysoce výkonným databázovým prostˇredím, ale také prostˇredím pro rychlý vývoj aplikací.

33

6

Hardwarové nároky serveru

Tato kapitola je zamˇeˇrena na monitorování poˇctu pˇrihlášených uživatel˚u, respektive kolikrát je uživatel cl pˇrihlášen, a velikosti zatížení serveru. Pro každého uživatele jsou vytvoˇreny urˇcité pˇrihlašovací skripty, které urˇcují co se bude spouštˇet po pˇrihlášení. Uživatel cl je urˇcený pouze pro pˇrihlašování k serveru, kde se poté spustí již pˇrihlašovací okno Clinicomu, kde se jednotliví uživatelé už hlásí svými loginy. Jedním ze skript˚u pro uživatele cl je .login, který je v domovském adresáˇri. Tento skript jsem editoval tak, aby se spouštˇely i mnou vytvoˇrené skripty, konkrétnˇe skripty login_program, logout_program a monitorovani. První dva jsou urˇceny pro monitorování poˇctu pˇripojení a poslední je urˇcen pro monitorování zatížení serveru. 6.1

Monitorování po£tu p°ipojení

Nyní se zamˇeˇrím na realizaci monitorování poˇctu pˇripojení již zmínˇeného uživatele cl. V domovském adresáˇri uživatele jsem vytvoˇril podadresáˇre statistika a grafy. Grafy budu popisovat v kapitole 6.2. V adresáˇri statistika se nacházejí již zmínˇené, spustitelné, skripty login_program (pˇrihlašovací skript), logout_program (odhlašovací skript) a logovací soubory log_cl, statistika.plot a statistika_vse. Pˇrihlašovací skript se spustí, jen když se uživatel cl pˇrihlásí. Zjistí si, kolik se ten den uživatel˚u cl pˇrihlásilo, danou hodnotu zvýší o 1 a zase poˇcet uživatel˚u uloží do odkládacího souboru log_cl. Jestliže je v ten den poprvé uživatel cl pˇrihlášen, informace ze souboru log_cl skript pˇrenese spolu s dnem, kdy se tolik uživatel˚u pˇrihlásilo do souboru statistika.plot. Zároveˇn se nastaví hodnota, v souboru log_cl na 1. Jak vypadá soubor statistika.plot je zobrazeno v levé cˇ ásti tabulky 6. Tabulka obsahuje pouze ˇrádky, které reprezentují dny, ve kterých se uživatel cl pˇrihlásil. Úmyslnˇe jsem zvolil nejprve datum ve formátu ddmmrr a poté poˇcet pˇrihlášených uživatel˚u. V pravé cˇ ásti tabulky je zobrazen soubor temp.plot. Formát je shodný se souborem statistika.plot a je rozšíˇren pouze o ˇrádky s 0, to proto, aby program Gnuplot i tuto skuteˇcnost také vynesl. Více se o programu Gnuplot pojednávám v kapitole 6.2. Pˇri každém pˇrihlášení se zanese do druhého logovacího souboru (statistika_vse) pˇresný cˇ as, ve formátu dd-mm-rrrr__hh:mm:ss, informace „pˇrihlášení“, cˇ íslo konsoly, ke které je pˇrihlášen a název poˇcítaˇce odkud se hlásí. Jak tento soubor vypadá, je znázornˇeno v tabulce 7. Jedná se pouze o cˇ ásteˇcný výpis souboru, kde jsou podtrženy ˇrádky spárované pˇríklady pˇrihlášení a odhlášení uživatele cl. Okomentovaný skript login_program se nachází v kapitole 10.2.

34

statistika.plot

temp.plot

180208

10

180208

10

190208

3

190208

3

200208

4

200208

4

250208

4

210208

0

020308

1

220208

0

030308

10

230208

0

240208

0

250208

4

260208

0

270208

0

280208

0

010308

0

020308

1

030308

10

Tabulka 6: Výpis souboru statistika.plot / temp.plot

14-04-2008__15:42:31 login

pts/26

pc PC-E218-115.ubmi.feec.vutbr.cz

14-04-2008__15:42:39 login

pts/27


14-04-2008__15:42:45 logout

pts/1


14-04-2008__15:42:56 login

pts/25


14-04-2008__15:43:36 login

pts/28


14-04-2008__15:43:45 logout

pts/2


14-04-2008__15:44:29 login

pts/29


14-04-2008__15:45:33 logout

pts/9


14-04-2008__15:47:04 logout

pts/15


14-04-2008__15:48:48 logout

pts/26


14-04-2008__15:50:11 logout

pts/28


14-04-2008__15:58:00 logout

pts/30


14-04-2008__15:58:09 login

pts/31


14-04-2008__16:01:12 logout

pts/6


14-04-2008__16:04:59 logout

pts/31


14-04-2008__16:12:16 logout

pts/29


14-04-2008__16:13:05 logout

pts/5


14-04-2008__16:13:19 login

pts/32


14-04-2008__16:28:15 login

pts/1


Tabulka 7: Výpis souboru statistika_vse

35

Protože se k serveru pˇrihlašuje pouze uživatel cl, odhlašovacího skript je se odvíjí od cˇ ísla konsole, které je individuální pro každého pˇrihlášeného uživatele cl. Nejprve si toto cˇ íslo zjistí, poté se podívá do systému, odkud je uživatel pˇrihlášen a to vypíše spolu s cˇ asem odhlášení, informací „odhlášení“ a cˇ íslem konsole do souboru statistika_vse (tabulka 7). 6.2

Vykreslení po£tu p°ipojení

Nyní si projedeme dadresáˇr grafy. Ten obsahuje 2 skripty (grafy, vykreslení grafu), které vykreslují grafy a výsledný obrázek statistika.png. Skript grafy je vytvoˇren tak, že po spuštˇení skriptu jsme vyzváni k zadání od kdy a pak do kdy chceme grafy vykreslit. Po zadání tˇechto informací ve formátu dd/mm/rr si nejprve zjistí, kolik má zadaný mˇesíc dní. Poté zaˇcne prohledávat, od zadaného datumu po jednotlivých dnech, logovací soubor statistika.plot až do zadaného datumu. Výsledky hledání si uchovává v souboru temp.plot. Po nalezení posledního datumu skript zavolá program Gnuplot, který umí vykreslovat grafy. Každý, kdo nˇekdy vypracovával nˇejakou technickou dokumentaci, se urˇcitˇe setkal s problémem prezentace výsledk˚u. Není vždy jednoduché navrhnout, vykreslit a poté uložit výsledný graf tak, aby byl jednoduše zaˇclenitelný do dokumentace. A právˇe pro tyto úˇcely se výbornˇe hodí Gnuplot. Dokáže zpracovávat jak funkce (knihovní i uživatelem definované), tak i datové soubory. Umožˇnuje definovat vzhled graf˚u co nejvíce podle pˇredstav "stvoˇritele". Datové soubory mohou mít „libovolnou“ strukturu, gnuplotu pouze rˇekneme, která cˇ ísla reprezentují jaké hodnoty, pˇrípadnˇe v jakém formátu jsou zapsána. Pro vykreslení graf˚u jsou použity parametry, typ výstupního souboru, výstupní soubor, šíˇrku cˇ ar, názvy a formáty os, zdrojový soubor a které soupce má použít pro vykreslení. Jak je uvedeno výše, vygenerovaný obrázek se jmenuje statistika.png a vzorový je v kapitole 7. Skripty login_program a logout_program se nacházejí v pˇrílohách v kapitole 10.3 6.3

Monitorování zatíºení

Tato podkapitola je zamˇeˇrena na realizaci monitorování zatížení uživatele cl. Pro realizaci sledování zatížení je v domovském adresáˇri uživatele vytvoˇren podadresáˇr monitorování, který obsahuje soubory pamet, seznam_procesu, monitorovani, proces a vytizeni_pocitace. Soubor monitorování je ve skuteˇcnosti spustitelný skript urˇcený právˇe pro monitorování. Výstupem toho skriptu je soubor vytizeni_pocitace, který obsahuje informace o vytížení serveru. Obsah tohoto souboru je okomentován na stránce 38. Dalšími jsou odkládací soubory pamet a seznam_procesu. Soubor pamet je urˇcen pro odkládání informací o alokované pamˇeti proces˚u sˆmsZ1000 spuštˇených všemi uživateli cl.

36

Name: State: SleepAVG:

bash S (sleeping) 78%

Jméno spu²t¥ného programu Co práv¥ proces d¥lá Kolik procent £asu je ve stavu sleep

Pid:

300

Process ID

PPid:

294

Rodi£ovský proces

TracerPid:

0

Uid:

500 500 500 500

Gid:

100 100 100 100

Napevno na hodnotu '0' ∗ ∗ ∗ ∗ Pole obsahuje UID , EUID , SUID , FSUID ∗ ∗ ∗ ∗ Pole obsahuje GID , EGID , SGID , FSGID

FDSize:

256

Velikost tabulky deskriptor· soubor·

Groups:

100

Seznam skupin do nichº proces pat°í

VmSize:

2432 kB

Obsazený LAP (Logický Adresový Prostor)

VmLck:

0 kB

Velikost uzam£ené pam¥ti (LAP i FAP)

VmRSS:

0 kB

Velikost p°id¥leného FAP (Fyzický Adresní Prostor)

VmData:

260 kB

VmStk:

24 kB

VmExe:

480 kB

VmLib:

1412 kB

Velikost datových stránek Velikost zásobníku Velikost kódu programu Velikost pam¥ti pro kód knihoven

Tabulka 8: Ukázka souboru status ∗

zkratky vysv¥tleny v kapitole 10.5

Proces je v GNU/Linuxu každý spuštˇený program, nahraný do pamˇeti. Ta se dˇelí na textový segment, datový segment a zásobník. Textový segment (vlastní kód programu) je v pamˇeti jen jednou, i když je program spuštˇen vícekrát. Každý proces má svoje jednoznaˇcné identifikaˇcní cˇ íslo PID (Process ID), vlastníka, prioritu a rodiˇce6 . Jádro každému novému procesu pˇriˇradí PID, které identifikuje proces po celou dobu jeho života. Pokud chci proces nˇejak spravovat, musím si zjistit jeho PID. Pokud spustím program z konsole cˇ i terminálu, zpravidla se stane ˇrídícím terminálem procesu a poskytne procesu standardní vstup, standardní výstup a standardní chybový výstup. PID konkrétního procesu m˚užeme zjistit napˇríklad z výpisu programu ps. Další možností je využití adresáˇre /proc, který mimo jiné obsahuje podadresáˇre, jejichž názvy jsou cˇ ísla jednotlivých proces˚u. Každý proces má tedy sv˚uj adresáˇr se soubory, ve kterých jsou kompletní informace o nˇem. Pro tuto realizaci jsou využity 2 soubory a to cmdline a status. Soubor cmdline obsahuje pouze název spuštˇeného procesu i s parametry. Status obsahuje informace o procesu. Nˇekteré jsou uvedeny v tabulce 8. Jaké je spojení cmdline a hledaných proces˚u? Procesy a tudíž i adresáˇre v /proc jsou v rozsahu 1 až 32768. Skript adresáˇre postupnˇe prochází a zjišt’uje zda náhodou soubor cmdline není spuštˇený sˆmsZ1000. Jestliže je, cˇ íslo PID si poznamená a zjistí hodnotu VmSize [kB]. 6 Rodi£ovský proces - Parent process je takový proces, který daný program spustí.

37

16:16 14.04.08 mem[kB] 94948

cpu[%] 0.0 users 2 pid :14605:18961

16:16 14.04.08 mem[kB] 180848

cpu[%] 0.0 users 2 pid :14605:18961

13:18 21.04.08 mem[kB] 42888

cpu[%] 0.0 users 1 pid :7952

13:19 21.04.08 mem[kB] 85776

cpu[%] 0.0 users 2 pid :7952:8900

13:19 21.04.08 mem[kB] 171552

cpu[%] 0.0 users 2 pid :7952:8900

13:20 21.04.08 mem[kB] 85776

cpu[%] 0.0 users 2 pid :7952:8900

13:20 21.04.08 mem[kB] 214440

cpu[%] 0.0 users 3 pid :7952:8900:10621

13:21 21.04.08 mem[kB] 128664

cpu[%] 0.0 users 3 pid :7952:8900:10621

13:22 21.04.08 mem[kB] 171552

cpu[%] 0.0 users 4 pid :7952:8900:10621:11673

13:22 21.04.08 mem[kB] 171552

cpu[%] 0.0 users 5 pid :7952:8900:10621:11673

13:22 21.04.08 mem[kB] 214440

cpu[%] 0.0 users 5 pid :7952:8900:10621:11673:12604

13:22 21.04.08 mem[kB] 471768

cpu[%] 0.0 users 6 pid :7952:8900:10621:11673:12604 :13125

13:22 21.04.08 mem[kB] 257328

cpu[%] 0.0 users 6 pid :7952:8900:10621:11673:12604 :13125

15:46 14.04.08 mem[kB] 2787856

cpu[%] 0.0 users 27 pid :324:371:578:809:2092:2221 :2658:7952:8900:10621:11349:12393:14605:17720 :19608:26028:26056:26119:26598:28774:28931 :29612:30084:30376:30880:31708:32347

Tabulka 9: Výpis souboru vytizeni_pocitace

Tuto hodnotu pˇripoˇcítá k hodnotˇe v souboru pamet. Skript monitorovani je vytvoˇren tak, aby se pˇri pˇrihlášení prvního uživatele cl spustil a pobˇeží, bude logovat informace, až do odhlášení posledního uživatele cl. Vždy 1 krát za minutu proskenuje systém a zjistí kolikrát je uživatel cl pˇrihlášený. Dále si poznamená, kolik má alokované pamˇeti proces sˆmsZ1000 a jak vytˇežuje procesor. Výstup tohoto skriptu je zapsaný do souboru vytizeni_pocitace, pˇriˇcemž obsahuje sloupce datum, ve formátu hh:mm dd.mm.rr, množství alokované pamˇeti (mem[kB] hodnota). Dále pak vytížení procesoru (cpu[%] hodnotu), poˇcet uživatel˚u (users poˇcet) a seznam proces˚u (pid :ˇcísla proces˚u). Pro názornost se podívejte na krátký výpis tohoto souboru, který je v tabulce 9. Celý okomentovaný skript naleznete v kapitole 10.4. Proˇc je na daný poˇcet uživatel˚u tak málo vytížený procesor? Odpovˇed’ je jednoduchá, NIS Clinicom, zjednodušenˇe, funguje na „dotazovacím“ principu, to znamená, že se klient zeptá na informaci o pacientovy a server, respektivˇe program sˆmsZ1000, se podívá na informace do databáze a odpoví klientovi (lékaˇri, sestˇre,...). Poté co odpoví, cˇ eká na další instrukce od klient˚u. Pamˇet serveru je pouze 1GB, je proto z tabulky 9 jasné, že jsou na ni mnohem vyšší nároky, než na procesor. Jak je možné, že alokovaná pamˇet’ proces˚u sˆmsZ1000 je skoro 3x

38

vyšší než fyzická? Odpovˇed’ je opˇet jednoduchá, zbylá (pˇresahající) pamˇet’ je virtualizovaná. Je-li kapacita LAP vˇetší, než je kapacita FAP, pak DAT (dynamická transformace adres ˇ Dynamic Address Translation) musí FAP virtualizovat. Ríkáme, že vzniká virtuální pamˇet’. Jak to vše v systémech funguje, popisuje kapitola 6.4. 6.4

Strategie p°id¥lování pam¥ti

Pokud je multitaskingový operaˇcní systém [15] v cˇ innosti, je rezidentní cˇ ást jádra operaˇcního systému umístˇena obvykle na zaˇcátku hlavní pamˇeti. Zbývající cˇ ást hlavní pamˇeti operaˇcní systém pˇridˇeluje zpracovávaným proces˚um. Jsou možné tyto zp˚usoby jejího pˇridˇelování: • Pˇridˇelování statických souvislých úsek˚u • Pˇridˇelování dynamických souvislých úsek˚u • Pˇridˇelování virtuálního adresového prostoru

P°id¥lování souvislých úsek· pam¥ti Pˇri pˇridˇelování statických souvislých úsek˚u je pamˇet’ po celou dobu bˇehu operaˇcního systému rozdˇelena na souvislé úseky. Umístˇení tˇechto úsek˚u se nemˇení. Proces se uloží do nejmenšího volného úseku, do kterého jej lze uložit. Pˇri pˇridˇelování dynamických souvislých úsek˚u operaˇcní systém vybere takovou souvislou volnou cˇ ást pamˇeti, která je dostateˇcnˇe velká na to, aby do ní mohl celý proces umístit. Pˇri výbˇeru volné souvislé cˇ ásti pamˇeti operaˇcní systém samozˇrejmˇe zvolí tu nejmenší možnou.

Virtuální pam¥´ V pˇrípadˇe, že je tˇreba vytvoˇrit program pˇresahující fyzickou pamˇet’ poˇcítaˇce, pak vzniká problém, který nelze pˇri použití výše uvedených metod pˇridˇelování pamˇeti vyˇrešit. Program nelze celý uložit do pamˇeti a spustit. Takový problém je popsán na obrázku 2, vˇcetnˇe mechanismu jeho rˇešení.

Proto byly tyto metody pozmˇenˇeny tak, aby bylo možné rozdˇelit program do nˇekolika cˇ ástí, které byly operaˇcním systémem do pamˇeti nahrávány a zpracovávány postupnˇe. Rozdˇelení programu do cˇ ástí a jejich postupné volání bylo dˇríve plnˇe v kompetenci programátora a pˇri vytváˇrení programu znamenalo pro programátora práci navíc. Proto byla navržena

39

Obrázek 2: Virtuální pam¥´ v¥t²í neº fyzická

metoda pˇridˇelování pamˇeti, která takové rozdˇelení programu do menších cˇ ástí a jejich postupné umist’ování do pamˇeti provádí automaticky. Principem této metody je, že jednotka DAT mapuje pˇri bˇehu procesu podle jeho potˇreb jeho logický adresový prostor na fyzický tak, jak to pˇredem stanovil operaˇcní systém. Procesor tak m˚uže pracovat v celém svém logickém prostoru, jako kdybychom mu rozšíˇrili fyzickou pamˇet’ na velikost pamˇeti logické. Byla vytvoˇrena jakási zdánlivá - virtuální pamˇet’. Organizace virtuální pamˇeti se však liší pro lineární a segmentovaný adresový prostor.

7

e²ení neo£ekávané události

Realizace neoˇcekávané události se soustˇredí na záložní napájení, softwarové propojení s pocˇ ítaˇcem a signalizaci výpadku elektrické energie. 7.1

Záloºní napá jení

Výpoˇcetní technika je po hardwarové stránce nejvíce náchylná na velké zmˇeny v napájení. At’ už se jedná o pˇrepˇetí, nebo o výpadky proudu, musí se výpoˇcetní technika chránit. Pro ochranu proti pˇrepˇetí existují tzv. pˇrepˇet’ové ochrany, které svojí funkcí omezují napˇet’ové

40

a proudové vlny, které vznikají a šíˇrí se po vodiˇcích metalických vedeních (napájecích, sdˇelovacích a datových atd.) obecných elektrických systém˚u. Tyto ochrany existují jak na silové pˇrívody k poˇcítaˇci, tak i na slaboproudé pˇrívody. Tato práce je zamˇeˇrena na ochranu proti výpadku napájecího proudu. Nejvýhodnˇejšími prostˇredky jsou záložní zdroje, které v sobˇe zahrnují už zmínˇenou ochranu proti výpadku proudu, ale také ochranu proti pˇrepˇetí silových i slaboproudých pˇrívod˚u k poˇcítaˇci. V dnešní dobˇe existují jak malé záložní zdroje pro jednotlivé poˇcítaˇce, tak modulární výkonné ochrany napájení pro servery, stˇrednˇe velké systémy a firemnˇe d˚uležité aplikace. Všechny záložní zdroje (UPS = nepˇrerušitelný zdroj energie) jsou stejné v tom, že sledují napájecí napˇetí a v pˇrípadˇe jeho výpadku ho ihned nahradí ze záložních baterií. Náhrada musí být „okamžitá“ tak, aby nedošlo k pádu poˇcítaˇce. Pro realizaci je zvolena malá Back-UPS Pro 1000 od firmy APC (American Power Conversion). Tato firma je na trhu již od roku 1981. Firma APC, zpoˇcátku dlouhou dobu nebyla ochotna poskytnout technické informace týkající se popisu komunikaˇcních protokol˚u svých UPS. Proto vznikl projekt Apcupsd, jehož autoˇri se rozhodli i za absence technických specifikací vytvoˇrit alternativní obslužný software pro tyto UPS. Apcupsd podporuje všechny bˇežné modely: napˇr. Back-UPS, Back-UPS Pro, Smart-UPS v/s, Smart-UPS a další. Kabel pro komunikaci s poˇcítaˇcem pˇres sériový port je zpravidla souˇcástí dodávky UPS. Apcupsd podporuje už i komunikaci pˇres USB. Tento projekt jsem vybral, pro realizaci komunikace s UPS. Z domovské stránky (http://www.apcupsd.com/) jsem stáhl aktuální program, ve zdrojovém kódu, verze 3.14.2. Po instalaci jsem provedl detekci apcaccess, která detekovala pˇripojenou pˇres USB. Otestováním, zda komunikace probíhá v poˇrádku, pˇríkazem (apctest), jsem zaˇcal realizovat signalizaci výpadku elektrické energie. 7.2

Detekce výpadku elektrické energie

Instalací vznikl v adresáˇri /etc podadresáˇr apcupsd [16]. Adresáˇr apcupsd obsahuje následující soubory: apccontrol, apcupsd.conf, commfailure, commok, changeme, offbattery, onbattery. Nˇekteré jsou konfiguraˇcní soubory a jiné spustitelné skripty, které se zavolají pˇri urˇcité události. Název skriptu odpovídá události, pˇri která se zavolá. Konfiguraˇcní soubor apcupsd.conf je ponechán v defaultním nastavení cˇ asu vypínání a signalizace výpadku. Jeho nejd˚uležitˇejší konfigurovatelné parametry jsou uvedeny níže (název parametru, nastavení a popis). • UPSCABLE usb - typ komunikaˇcního kabelu

41

• UPSTYPE usb - typ ups • LOCKFILE /var/lock - cesta k zamykacímu souboru, aby více aplikací nepˇristupovalo k portu usb • NETSERVER off - pokud je zapnuto, apcupsd bude poskytovat informace o stavu UPS pˇres sít’ • BATTERYLEVEL 5 - minimální nabití baterie (%), pokud nabití baterie klesne pod tuto mez, shutdown systému • MINUTES 3 - odhad UPS-ky, jak dlouhou dobu jsou pˇri výpadku sítˇe ještˇe schopny zajistit napájení. Pokud tato doba klesne pod mez zadanou parametrem MINUTES, iniciuje UPS shutdown systému. • TIMEOUT 0 - cˇ as v sekundách, po jehož vypršení pˇri výpadku napájení bude spuštˇen shutdown systému (0 vypnuto) Jako je tomu u vˇetšiny program˚u v GNU/Linuxu, tak i u programu apcupsd je vytvoˇ ˇren po instalaci logovací soubor apcupsd.events v adresáˇri /var/log. Cásteˇ cný výpis logovacího souboru apcupsd.events je na obrázku 3. Tento výpis je vytvoˇren pˇríkazem tail -9 apcupsd.events, to znamená, že vypisujeme posledních 9 ˇrádk˚u souboru. Dále je vidˇet, že UPS detekovala pˇetivteˇrinový pokles napájecího napˇetí nebo výpadek elektrické energie a poté také náš testovací výpadek elektrické energie. Pˇri tomto výpadku UPS vydržela 37 minut napájet server ze sítˇe, pˇriˇcemž byli pˇripojeni 3 uživatelé cl z textového terminálu. Ve varovných emailech uvádím radˇeji cˇ as 15 až 20 minut, protože nevím, jak hodnˇe je baterie vybitá pˇred výpadkem elektrické energie.

Obrázek 3: áste£ný výpis souboru apcupsd.events

42

Bylo nutné pouze editovat skript onbattery (viz obrázek 4), který se zavolá pˇri výpadku elektrické energie. Do tohoto konfiguraˇcního souboru jsem pˇridal rˇádek, který rˇíká, že se má spustit skript smtp.pl (ˇrádek 4) pro posílání sms a emailových zpráv pˇri výpadku elektrické energie. Dále jsem pˇridal promˇennou UZIVATEL (ˇrádek 6) a dopsal také odkaz na ni (ˇrádek 20). Její hodnotou jsou lokální uživatelé cl a friedl, kterým se také pošle varovný email. M˚užeme do této promˇenné pˇridat další uživatele, musí však také býti oddˇeleni mezerou.

Obrázek 4: Výpis souboru onbattery

Mnou navržený skript smtp.pl jsem napsal v perlu7 a umístil jsem ho do adresáˇre /bin. Tento skript si nejprve zavolá modul smtp, poté nastaví odchozí smtp server a od koho mail pˇrijde. Poté již odešle na jednotlivé emailové adresy. Testoval jsem funkˇcnost posílání email˚u i na mobil. Pˇridal jsem proto do skriptu emailovou adresu mobilního telefonu, toto podporuje Vodafone i O2 . Celý okomentovaný skript smtp.pl je v kapitole 10.1. 7 Perl je interpretovaný programovací jazyk vytvo°ený Larry Wallem v roce 1987. S rozvojem internetu se Perl stal velmi populárním nástrojem pro tvorbu CGI skript· (umoº¬ují vytvá°et dynamické HTML stránky, stránky závislé na aktuálních datech, obsahu r·zných soubor·, £ase nebo adrese po£íta£e, ze kterého je Va²e stránka nav²tívena.)

43

8

Realizace tenkého klienta

Jak uvádím v kapitole 2.9, je použit jako tenký klient live distribuce Slax pro pˇripojení k serveru NIS Clinicom. Dˇríve než se realizuje první pˇripojení, je nutné upravit klávesovou mapu, protože p˚uvodní klávesnice má odlišná tlaˇcítka (viz obrázek 5). Jak zmˇenit klávesovou mapu a vytváˇrit novou, je popsáno v následujících kapitolách. V kapitole 8.3 je popsán skript, kterým se realizuje pˇripojení k NIS Clinicom.

Obrázek 5:

Vzhled p·vodní klávesnice

Z tohoto skriptu a klávesové mapy je vytvoˇren nový Slaxový modul. Vytvoˇrení a zavedení vlastního modulu do Slaxu je popsáno v kapitole 8.3 8.1

Vytvo°ení klávesové mapy

Postup vytvoˇrení a nastavení platí pro GNU/Linuxové distribuce, vycházející ze Slackware. Pro jiné distribuce m˚uže být odlišné nastavení a cesty k jednotlivým soubor˚um. Nejprve je nutné zjistit, jakou klávesovou mapu používám. Ve Slackwaru je tato informace v souboru /etc/rc.d/rc.keymap. M˚uj Slackware používá cz-cp1250.map.gz v adresáˇri/usr/share/kbd/keymaps/i386/qwerty/. Nyní se musíme pˇrepnout do adresáˇre cd /usr/share/kbd/keymaps/i386/qwerty/ a poté vytvoˇríme kopii výše uvedené klávesové mapy cp cz-cp1250.map.gz cz-cp1250-clinicom.map.gz. Nejprve malý slovníˇcek použitých pojm˚u: • scancode - kódy, které jsou pˇrímo z klávesnice

44

• keycode - kódy klávesy, které pˇrijímá poˇcítaˇc z klávesnice • klávesa - zde myšleno napˇr. F13, h nebo tˇreba Tab Pˇred vytvoˇrením vlastní mapy,[17] musíme zjistit, jaké klávesy budeme potˇrebovat pˇremapovat (= zmˇenit pˇríkazy, které posílají). Já jsem mˇel práci z cˇ ásti ulehˇcenou, protože jsem vˇedˇel, o které klávesy se bude jednat a kam se budou pˇremapovávat (viz. tabulka 11). Informace jsem mˇel z programu KoalaTerm. Pro použití v GNU/Linuxu je potˇreba najít keycode kláves, jejichž funkce se bude mˇenit (jak najít keycode popisuje kapitola 8.2). Jinak musíme experimentovat a zkoumat soubor /etc/termcap. Tento soubor v sobˇe obsahuje databázi terminál˚u, která rˇíká program˚um, co jsou schopny provádˇet. Tam je také uvedeno, že p˚uvodní klávesa Do posílá pˇríkazy jako klávesa F16. Jaké klávesy bylo nutné pˇremapovat, je uvedeno v tabulce 11. 8.2

Keycode kláves

Keycode kláves zjistíme pˇríkazem showkey8 . Po spuštˇení programu uvidíme ve výpisu „kód klávesy 28 uvolnˇení“ (obr. 6). Klávesový kód 28 pˇrísluší Enteru, to znamená, že program zaregistroval uvolnˇení klávesy Enter. To samé platí pro kód 1, který pˇrísluší klávese Esc. Opˇet stisknutí (press) a uvolnˇení (release) klávesy. Poˇckáme-li 10 sekund bez stisknutí klávesy, showkey se sám ukonˇcí, jinak bude zobrazovat klávesové kódy kláves, které stiskneme.

Obrázek 6:

Textový výpis programu showkey

Nyní máme 2 možnosti jak nastavit, co mají jednotlivé klávesy dˇelat: 8 showkey - ukazuje nám scancody a keycody. Jedná se o konzolový program, který bývá sou£ástí distribuce.

45

showkey scancode

setkeycodes scancode

0x68

68

0xe0 0x68

e068

Tabulka 10: P°íklad pro scancody Enteru

P°i°azení keycod· ke scancod·m Volné keycody pˇriˇradíme ke scancod˚um. Proto musíme spustit showkey znovu, tentokrát s parametrem -s, který zajistí, že showkey nebude ukazovat keycody ale scancody. Nyní je cílem najít v klávesové mapˇe tolik volných rˇádk˚u (keycod˚u), kolik potˇrebujeme namapovat tlaˇcítek na naší klávesnici. Nˇekteré keycody jsou volné už od pohledu (nemají zatím definovaný žádný pˇríkaz). Výpis je podobný, jen tam chybí „keycode 28 uvolnˇení“. Namísto toho tam je „0x9c“, což je scancode puštˇení Enteru. Keycode je pˇri zmáˇcknutí i puštˇení klávesy stejný, kdežto scancode je jiný (viz tab. 10). V konzoli máme k dispozici pouze 127 keycod˚u. Nyní pˇrichází ke slovu program setkeycodes9 , kterým volné keycody pˇriˇradíme ke scancod˚um. Setkeycodes používá lehce odlišný zápis scancod˚u. Pˇríklad skriptu se scancodama: #!binbash #setkeycodes scancode keycode setkeycodes e06a 85 setkeycodes e069 89 Skript musíme umístit napˇr. do /etc/rc.d/rc.local, aby se spustil vždy pˇri startu poˇcítaˇce. Tato varianta není nevyhovující, když nepotˇrebujeme pˇridávat tlaˇcítka kláves do klávesové mapy, všechny používané tam již jsou. Je proto namístˇe volba 2. varianty a tj. úprava klávesové mapy.

Úprava klávesové mapy Podle návodu výše, jsme zjistili klávesové kódy kláves, které potˇrebujeme pˇremapovat pro správnou funkci NIS Clinicom. Nyní je potˇreba otevˇrít soubor cz-cp1250-clinicom.map.gz v editoru mcedit. Z mnoha ˇrádk˚u zaˇcínajících „keycode“ a cˇ íslem kódu, musíme vybrat ty, které budeme potˇrebovat zmˇenit. K tˇemto klávesovým kód˚um poté „natvrdo“ pˇriˇradíme pˇríkazy pro jednotlivé klávesy. 9 setkeycodes - mapuje scancody na keycody v konzoli (bývá sou£ástí distribuce)

46

Vezmˇeme napˇríklad klávesu F2: pˇríkazem showkey zjistíme, že její keycode je 60. P˚uvodní pˇríkaz této klávesy byl F2 a nový pˇríkaz pro tuto klávesu je F7. Toto vidíme i v tabulce 11, kde prostˇrední 3 sloupce pˇredstavují cˇ ást p˚uvodního souboru, pˇriˇcemž pravý sloupec pˇredstavuje nový pˇríkaz pro danou klávesu. Nyní již chybí vytvoˇrit skript, který zavede do systému vytvoˇrenou klávesovou mapu a pˇripojí se ssh k NIS Clinicom. klávesa

keycode

p·vodní p°íkaz

nový p°íkaz

Escape

F16

ESC

keycode

1

F1

keycode

59

F1

F6

F2

keycode

60

F2

F7

F3

keycode

61

F3

F8

F4

keycode

62

F4

F9

F5

keycode

63

F5

F10

F6

keycode

64

F6

F11

F7

keycode

65

F7

F12

F8

keycode

66

F8

F13

F9

keycode

67

F9

F14

F10

keycode

68

F10

F17

F11

keycode

87

F11

KP_Subtract

F12

keycode

88

F12

KP_Multiply

Scroll Lock

keycode

70

Scroll_Lock

Help

Enter

keycode

28

Return

Return

Delete

keycode

111

Remove

Remove

Home

keycode

102

Find

Find

End

keycode

107

Select

Select

Page Up

keycode

104

Prior

Prev

Page Down

keycode

109

Next

Next

Numpad Enter

keycode

96

KP_Enter

Enter

Tabulka 11: Nastavení klávesové mapy

8.3

P°ipojení ssh k NIS Clinicom

Upravenou klávesovou mapu, umístˇenou v adresáˇri /usr/share/kbd/keymaps/i386/qwerty/, zavedeme pˇríkazem loadkeys cz-cp1250-clinicom.map.gz. V tuto chvíli máme klávesovou mapu aktivovanou a vytvoˇríme ssh pˇripojení s parametrem -l cl. Po odhlášení nesmí chybˇet zavedení zpˇet p˚uvodní klávesové mapy, nyní pˇríkazem loadkeys cz-cp1250.map.gz. Celý skript pojmenujeme napˇr. ssh_clinicom a bude vypadat následovnˇe:

47

#! /bin/bash loadkeys cz-cp1250-clinicom.map.gz #nastavení kódování pro ssh pˇripojení k serveru LC_ALL=cs_CZ luit ssh clinicom.ubmi.feeec.vutbr.cz -l cl loadkeys cz-cp1250.map.gz

8.4

Vytvo°ení modulu pro Slax

Podle obecného popisu z kapitoly 2.9, musíme nejprve vytvoˇrit v pracovním adresáˇri adresáˇrovou strukturu. Ta musí odpovídat tomu, kam chceme pˇrenést své skripty. V pracovním adresáˇri bude proto následující struktura /usr/share/kbd/keymaps/i386/qwerty/. To znamená, že pˇri zavedení modulu se pouze tato struktura pˇresune do koˇrenového adresáˇre Slaxu. Vytvoˇrený skript ssh_clinicom musí být umístˇen v adresáˇrové struktuˇre /usr/bin/. Nyní již vytvoˇríme z adresáˇre nový modul pro Slax pˇríkazem dir2lzm název_adresáˇre název_nového_modulu.

48

9

Záv¥r

V této diplomové práci jsem se seznámil s nemocniˇcním informaˇcním systémem Clinicom na ÚBMI. Dále jsem prostudoval hardwarové nároky distribuce Fedora Core, tenkých klient˚u a konkrétního rˇešení projektem LTSP. Na server NIS Clinicom jsem pro sledování hardwarových nárok˚u umístil 3 skripty, které sledují vytížení serveru. První 2 skripty logují jednotlivé cˇ asy pˇrihlášení a poˇcty pˇrihlášených uživatel˚u v daných dnech. Pro pˇrehlednˇejší zhodnocení poˇct˚u pˇrihlášení v jednotlivých dnech, je vytvoˇren nadstavbový skript pro generování graf˚u. V tomto skriptu si uživatel m˚uže zvolit rozmezí dn˚u, ve kterých ho zajímá statistika pˇrihlášení. Realizace tˇechto skript˚u a pˇresný popis najdete v kapitolách 6.1 a 6.2. Posledním, tˇretím, skriptem sledujícím vytížení serveru, je skript pro monitorování alokované pamˇeti a vytížení procesoru na serveru. Ten se spustí, když se pˇrihlásí první uživatel cl a bˇeží až do odhlášení posledního. To znamená, že pˇri pˇrihlášení více uživatel˚u je tento skript spuštˇen pouze 1 krát. Jeho cˇ innost spoˇcívá v tom, že 1 krát za minutu proskenuje systém, zjistí, kolikrát je spuštˇen proces sˆmsZ1000, kolik mají všechny tyto procesy alokované pamˇeti a jak hodnˇe zatˇežují procesor. Sledování pouze 1 krát za minutu jsem zvolil proto, abych umˇele nezvyšoval zatížení serveru. Ze získaných hodnot jsem zjistil, že proces sˆmsZ1000 pˇri spuštˇení alokuje do 50 MB logického adresového prostoru. I když je pˇri vícenásobném spuštˇení, vlastní kód programu, v pamˇeti umístˇen pouze jedenkrát, je 1 GB fyzické pamˇeti nedostateˇcný. Pˇri vyšším poˇctu spuštˇení alokuje, i pro základní operace, necelé 3 GB pamˇeti. Nebyly mi dostupné informace, které další procesy souvisejí s cˇ innostmi NIS Clinicom a spuštˇenou aplikací, proto mohu pouze odhadnout, že danou konfiguraci serveru by nebylo možné v praxi využít. Myslím si, že by se pˇri ostrém provozu pˇridalo ještˇe zatížení od prohledávání rozsáhlejší databáze, nároˇcnˇejších operací i napˇr. NetAccessu. Další cˇ ástí, kterou jsem se zabýval v této diplomové práci, bylo ˇrešení neoˇcekávané události, konkrétnˇe výpadku elektrického proudu. Toto jsem vyˇrešil pˇridáním záložního zdroje, který monitoruje stav sítˇe a zároveˇn stav svých baterií. V okamžiku výpadku elektrické energie, jsou záložní baterie nabité a server m˚uže ještˇe cca 15 až 20 min pracovat bez omezení. Pˇri zbytkové kapacitˇe baterií 5% pošle záložní zdroj serveru informaci, aby vše uložil a vypnul se. Tím je zajištˇeno, že nedojde ke ztrátˇe neuložených dat, nekorektnímu vypnutí systému a poškození hardwaru. Záložní zdroj má v systému své skripty, které se spustí pˇri urˇcitém stavu baterie, resp. záložního zdroje. Tohoto jsem využil i já a pˇri pˇrepnutí záložního zdroje na baterii se spustí skript, který pošle na danou emailovou adresu varovný email o výpadku proudu. Emailová

49

adresa m˚uže být i mobilního telefonu. Více popsaná realizace je v kapitole . Jsem zastáncem toho, že když server bˇeží na GNU/Linuxové distribuci Red Hat, tak proˇc by se klienti mˇeli pˇripojovat z MS Windows. Proto jsem realizoval pˇripojení z jiného GNU/Linuxového stroje. Pˇri realizaci jsem nejprve musel používanou klávesovou mapu upravit, tj. musel jsem nˇekteré klávesy pˇremapovat. Poté tuto klávesovou mapu zavést do systému, aby správnˇe fungovaly jednotlivé klávesy. Pro realizaci jsem použil live distribuci Slax a posloužila mi jako d˚ukaz, že lze se pˇripojit i z GNU/Linuxu. Jsem také toho názoru, že když firma vyvíjí sv˚uj software, mˇel by býti nezávislý na operaˇcním systému. Proto jsem byl velice potˇešen informací o NetAccess pˇrístupu k NIS Clinicom. Zároveˇn mˇe potˇešila informace o možnosti realizace pracovních stanic, tenkými klienty, kterou firma SMS již podporuje. Tencí klienti jsou v této diplomové práci porovnáni s realizací tlustých klient˚u (viz kapitola 2.11). Moje myšlenka nezávislého operaˇcního systému vychází z toho, že bych nemˇel být nucen platit drahé licence, když mohu používat svobodný software, který je pro mˇe dostupný za mnohem nižší náklady. Firma SMS již udˇelala první krok a to pˇrístupem pˇres NetAccess. Touto prací jsem naznaˇcil, co by se mˇelo zvážit a kudy by se mohly a možná mˇely odvíjet kroky nejenom zdravotních institucí a ministerstva zdravotnictví, ale všech, kteˇrí zvažují aktualizaci svého systému, pˇrípadnˇe pˇrechod na nový systém. Zároveˇn jsem ukázal využití stávajícího hardware v homogením prostˇredí pˇri realizaci tenkými klienty.

50

10 10.1

P°ílohy Skript posílání zpráv o výpadku

# pˇripojení modulu smtp #use Net::SMTP; # nastavení adresy smtp serveru $smtp = Net::SMTP->new(’fest.stud.feec.vutbr.cz’); # nastavení od koho mail pˇrišel $smtp->mail(’[email protected]’); # adresy na kterou má email dojít $smtp->to(’[email protected]’); $smtp->to(’[email protected]’); $smtp->to(’[email protected]’); $smtp->data(); # nastaví do zdrojového kódu emailu cílovou adresu $smtp->datasend("To: janfriedlseznam.cz\n"); #nastavení subjektu emailu $smtp->datasend("Subject: ALARM: Clinicom vypadek proudu!!!\n"); $smtp->datasend("\n"); #text zprávy $smtp->datasend("Vypadl proud na serveru Clinicom!!! 15-20 min do vypnutí serveru.\n"); #ukonˇcení zprávy $smtp->dataend(); $smtp->quit;

10.2

Skript statistika p°ihlá²ení

#! /bin/sh #hlaviˇcka, skriptu ############################ LOGVACI PROGAM PRO UZIVATELE CL #AUTOR: Jan FRIEDL #EMAIL: [email protected] # Vytvoreno jako diplomova prace na UBMI ve sk. roce 2007/2008 ########################## #

51

# defaultni cesta: /home/cl/statistika/login_program # # spousteni se provadi v logovacim skriptu: /home/cl/.login ############################################# ˇ #PROMENNÉ ############################################# #cl_dnes .......poˇcet dnes pˇrihlášených uživatel˚u cl #zapsání do promˇenných do dn = dnešni, dn_den = dnešní den (kolikátého je) #zapsání do promˇenných do dn = dnešni, dn_mesic = dnešní mˇesíc (kolikátého je) dn_den=$(date +%d) dn_mesic=$(date +%m) #zapsání do promˇenných do log = logovací soubor log_cl, log_den = den zmˇeny/vytvoˇrení logovacího souboru #zapsání do promˇenných do log = logovací soubor log_cl, log_mesic = mˇesíc zmˇeny/vytvoˇrení logovacího souboru log_den=$(date +%d -r /home/cl/statistika/log_cl) log_mesic=$(date +%m -r /home/cl/statistika/log_cl) log_rok=$(date +%y -r /home/cl/statistika/log_cl) #pˇresný cˇ as ve kterém se uživatel pˇrihlásil prave_ted=$(date +%d-%m-%-Y__%H:%M:%S) #z jakého stroje se poslední uživatel pˇrihlásil stroj=$(last -a -x | head -n 1 | colrm 1 60) #vyfiltrování konsole uživatele konsole=$(tty | colrm 1 5) #zapsání aktuálního cˇ asu, konsole a odkud stroj odkud se uživatel pˇrihlašuje echo $prave_ted "login " $konsole "pc" $stroj » /home/cl/statistika/statistika_vse ############################################# #FUNKCE ############################################# #další pˇrihlášení uživatele CL #zvýší poˇcet pˇrihlášení uživatele CL o jedniˇcku function dalsi_prihlaseni(){ #zjištˇení hodnoty ze souboru log_cl, zvýšení o 1 a znovu uložení cl_dnes=$(cat /home/cl/statistika/log_cl) cl_dnes=$(($cl_dnes+1))

52

echo $cl_dnes > /home/cl/statistika/log_cl } ############################################# #první pˇrihlášení uživatele CL #zapíše do souboru statistika.plot kolik se v pˇredchozím dnu pˇrihlásilo uživatel˚u a vynuluje logovací soubor function prvni_prihlaseni() { cl_dnes=$(cat /home/cl/statistika/log_cl) echo $log_den$log_mesic$log_rok $cl_dnes » /home/cl/statistika/statistika.plot ############################################# prvni=1 echo $prvni > /home/cl/statistika/log_cl } ############################################# #konec funkce ############################################# #když byl logovací soubor log_cl dnes zmˇenˇen zavola se funkce další pˇrihlášení jinak první pˇrihlášení if [ $dn_den = $log_den ]; then if [ $dn_mesic = $log_mesic ]; then dalsi_prihlaseni else prvni_prihlaseni fi else prvni_prihlaseni fi exit 0 10.3

Skript grafy a vykreslení grafu

Grafy #! /bin/bash #hlaviˇcka, která se zobrazí echo "==========================================================" echo "program: VYKRESLENI STATISTIKY PRIHLASENI" echo "autor: Jan FRIEDL" echo "SKOLNI ROK: 2007 / 2008"

53

echo "==========================================================" #výzva, aby uživatel zadal datum od kdy do kdy chce vykreslit graf echo -n "Zadej datum od kdy chces vykreslit graf [dd/mm/rr] :" #pˇreˇctení zadaného datumu IFS="/" read od_den od_mesic od_rok echo -n "Zadej datum do kdy chces vykreslit graf [dd/mm/rr] :" IFS="/" read do_den do_mesic do_rok #funkce, která pˇriˇradí poˇcet dn˚u do promˇenné v zadaném mˇesíci function mesic_dni () case "$od_mesic" in 01 )pocet_dnu=31;; 02 )pocet_dnu=28;; 03 )pocet_dnu=31;; 04 )pocet_dnu=30;; 05 )pocet_dnu=31;; 06 )pocet_dnu=30;; 07 )pocet_dnu=31;; 08 )pocet_dnu=31;; 09 )pocet_dnu=30;; 10 )pocet_dnu=31;; 11 )pocet_dnu=30;; 12 )pocet_dnu=31;; esac #zavolaní funkce mesic_dni #cyklus probíhá od zadaného do zadaného datumu until [ $od_den$od_mesic$od_rok == $do_den$do_mesic$do_rok ]; do #jestliže se dané datum nachází v logovacím souboru, pˇresune se jeho hodnota do temp.plot, jinak se tam pˇresune 0 if grep $od_den$od_mesic$od_rok /home/cl/statistika/statistika.plot > /dev/null then grep $od_den$od_mesic$od_rok /home/cl/statistika/statistika.plot » temp.plot else

54

echo $od_den$od_mesic$od_rok 0 » temp.plot fi #toto kontroluje, jestli už není konec mˇesíce, aby se pˇrípadnˇe zvýšila hodnota mˇesíce o 1 a den v mˇesíci na 1 if [ $od_den == $pocet_dnu ]; then od_mesic=‘expr $od_mesic + 1‘ if [ $od_mesic -lt 10 ]; then od_mesic=0$od_mesic fi #kontroluje jestli už není konec roku if [ $od_mesic == 13 ]; then od_mesic=01 od_rok=‘expr $od_rok + 1‘ if [ $od_rok -lt 10 ]; then od_rok=0$od_rok fi fi od_den=01; #zavolani funkce mesic_dni else od_den=‘expr $od_den + 1‘ if [ $od_den -lt 10 ]; then od_den=0$od_den fi fi done #zavolání programu gnuplot gnuplot "/home/cl/grafy/vykresleni_grafu" exit 0

55

Vykreslení grafu #nastavení šíˇrky grafu set boxwidth 0.2 relative #nastavení stylu grafu set style fill solid 0.25 border #nastavení vzorkování grafu set samples 50,50 #nastavení výstupního formátu set terminal png; #nastavení výstupního souboru set output "/home/cl/grafy/statistika.png"; #nastavení názvu grafu set title "STATISTIKA PRIHLASENI"; #nastavení mˇrížky set grid; #nastavení, že x-ová osa bude zpracovávat data set xdata time; #formát vstupních dat set timefmt "%d%m%y "; #formát výstupních dat set format x "%d.%m.%y"; #rozsah osy y set yrange [-1:*] #popsání osy y set ylabel "Pocet prihlaseni v jednotlivych dnech"; #roztažení plochy pod grafem smˇerem dol˚u set bmargin 8 #popsání a umístˇení názvu osy set xlabel "Dny" 0.0,-3 #skrývá legendu set nokey set grid noytics set grid noxtics #formát vykreslení datumu na ose x set xtics rotate 86400; #samotné vykreslení grafu, pˇriˇcemž bere 1 a 2 sloupec ze souboru a typ grafu

56

plot "temp.plot" using 1:2 title ’Pocet prihlaseni / v danem dnu’ with boxes; pause -1 "stiskni Enter"; 10.4

Skript monitorování zatíºení

#!/bin/bash #ˇcekání 10s sleep 10s #pˇrepnutí do adresáˇre proc cd /proc #vynulování promˇenné pameti a pˇriˇrazení prázdného sloupce do promˇenné proces pameti=0 proces=”; #vynulování vytížení procesu vytizeni_procesoru=0; #vypsání aktuálních proces˚u do souboru ps acx > /home/cl/monitorovani/seznam_procesu #zjistí, kolikrát je spuštˇen skript monitorování spuštˇen, jestliže více jak 1, ukonˇcí tento skript pocet_spusteni=‘grep /home/cl/monitorovani/monitorovani /home/cl/monitorovani/seznam_procesu | wc -l‘ if [ "$pocet_spusteni" -gt 1 ]; then exit 0 fi; #jestliže existuje ještˇe proces s Z1000 pokraˇcuje dál while ps ax | grep Z1000 | grep -v grep > /dev/null; do for ii in $(seq 1 32768) ; do #zkoumá, jestliže existuje adresáˇr s daným cˇ íslem, jestliže ano, zkoumá zda je to procesu Z1000 if test -d $ii ; then if grep Z1000 $ii/cmdline > /dev/null 2>&1; then #zjistí si, kolik má alokované pamˇeti a pˇripoˇcte hodnotu do souboru pamet pameti=$(cat /home/cl/monitorovani/pamet) pameti=‘expr $pameti + $(cat $ii/status|grep VmSize|colrm 1 7 | colrm 17 50 )‘

57

echo $pameti > /home/cl/monitorovani/pamet #zaznamená si cˇ íslo procesu proces=$proces:$ii #zjistí si, jak daný proces vytˇežuje procesor a pˇriˇcte tuto skuteˇcnost k dané hodnotˇe procesor=‘ps h -o "%cpu" $ii‘ vytizeni_procesoru=‘expr $vytizen_procesor + $procesor‘ fi ; fi ; done #zjistí si, kolik je aktuálnˇe pˇrihlášených uživatel˚u cl kolik=$(who | grep cl | wc -l) #zjistí si aktuální cˇ as minuta=$(date +%M) hodina=$(date +%H) den=$(date +%d) mesic=$(date +%m) rok=$(date +%y) #zapíše všechny zjištˇené informace o procesech uživatele cl do souboru vytizeni_pocitace echo $hodina:$minuta $den.$mesic.$rok mem[kB] $pameti cpu[%] $vytizeni_procesoru users $kolik pid $proces » /home/cl/monitorovani/vytizeni_pocitace #ˇceká 50s sleep 50s #vypíše seznam proces˚u do souboru a jestliže existuje proces Z1000 pokraˇcuje odzaˇcátku, jinak skonˇcí ps ax > /home/cl/monitorovani/seznam_procesu if grep Z1000 /home/cl/monitorovani/seznam_procesu > /dev/null; then ii=0; pameti=0; echo $pameti > /home/cl/monitorovani/pamet proces=”; vytizeni_procesoru=0; fi; done exit 0;

58

10.5

Obrázky

Obrázek 7: Obrázek statistika p°ihlá²ení

59

Reference [1] Otevˇrená encyklopedie WIKIPEDIE, cˇ lánek Svobodný software [online], poslední úpravy 21:08, 27.4.2008. Dostupné z . [citováno 2008-05-11].

[2] Otevˇrená encyklopedie WIKIPEDIE, cˇ lánek Linux [online], poslední úpravy 21:36, 21.4.2008. Dostupné z . [citováno 2008-05-11].

[3] Otevˇrená encyklopedie WIKIPEDIE, cˇ lánek Linuxové distribuce [online], poslední úpravy 02:57, 4.4.2008. Dostupné z . [citováno 2008-05-11]. [4] Otevˇrená encyklopedie WIKIPEDIE, cˇ lánek Red Hat [online], poslední úpravy 20:25, 22.4.2008. Dostupné z . [citováno 2008-05-11].

[5] Otevˇrená encyklopedie WIKIPEDIE, cˇ lánek Red Hat Enterprise Linux [online], poslední úpravy 01:37, 14.3.2008. Dostupné z . [citováno 2008-05-11].

[6] Otevˇrená encyklopedie FedoraWiki, cˇ lánek Fedora Core [online], poslední úpravy 16:59, 16.11.2007. Dostupný z . [citováno 2008-05-11].

[7] WWW stránky projektu Slax. Dostupné z . [citováno 2008-05-11].

60

[8] Suchý, O. Thin Computing - Linuxové tenké klienty pro korporátní prostˇredí Dostupný z WWW: . [citováno 2008-05-11].

[9] McQuillan, J. LTSP - Linux Terminal Server Project - v4.1 [online], 2004-06-20. Dostupný z . [citováno 2008-05-11].

[10] Otevˇrená encyklopedie FedoraWiki, cˇ lánek Start Linuxu [online]. poslední úpravy 18:38, 10.3.2007. Dostupné z . [citováno 2008-05-11].

[11] KASAL, P. Lékaˇrská informatika, Karolinum - nakladatelství Univerzity Karlovy, Praha, 1998

[12] Dvoˇrák, M. Lékaˇrská informatika, studijní materiály k pˇredmˇetu Zdravotnické informaˇcní systémy. 2007

ˇ [online], bˇrezen 2008. Do[13] Medimarket s.r.o.,Pˇrehled firem nabízejících NIS v CR stupné z

[14] WWW stránky firmy SMS.2008 [online]. Dostupné z . [citováno 2008-05-11].

[15] Sobˇeslavský, M. Výukový systém - virtuální pamˇet’, Srpen 2007. Bakaláˇrská práce ˇ na Elektrotechnické fakultˇe Ceského vysokého uˇcení technického v Praze. Vedoucí diplomové práce Ing. Jan Trdliˇcka, Ph.D.

61

[16] Häring, D. Apcupsd - free obslužný software záložních zdroj˚u APC [online], 29. cˇ ervence 2001. Dostupné z . [citováno 2008-05-11].

ˇ [17] ŠTEPÁNEK, Z. Multimediální a jinak vylepšené klávesnice [online], 26.1.2004. Dostupné z . [citováno 2008-05-11].

62

Výb¥r pouºitých zkratek AIS

Ambulantní Informaˇcní Systém

APC

American Power Conversion = firma vyrábˇející UPS

COSTAR

Computer Stored Ambulatory Record = poˇcítaˇcovˇe uložený ambulantní záznam

DHCP

Dynamic Host Configuration Protokol = služba pˇridˇelování konfigurace TCP/IP klient˚um

DSS EGID

Decision Support System = systém˚u pro podporu rozhodování Effective GID = Efektivní GID

EUID

Effective UID = Efektivní UID

Freax

kombinace slov „free“ (svobodný), „freak“ (výstˇrední, mimoˇrádný)

FSGID

a písmene X jako oznaˇcení systému unixového typu File System GID = GID pro systém soubor˚u

FSUID GID

File System UID = UID pro systém soubor˚u Group ID = identifikaˇcní cˇ íslo skupiny

GNU GPL

GNU’s Not Unix = rekurzivní zkratka GNU Není Unix General Public License = Všeobecná Veˇrejná Licence

GUI

Graphics User Interface = Grafického Uživatelského Rozhraní

IS

Informaˇcní Systém

KIS LAP

Klinický Informaˇcní Systém Logický Adresový Prostor

Linux

Linus˚uv Minix

LIS

Laboratorní Informaˇcní Systém

LTSP NFS

Linux Terminal Server Projekt Network File System = Sít’ový Souborový Systém

NIS

Nemocniˇcní Informaˇcní Systém

PDA

Personal Digital Assistant = Osobní Digitální Pomocník Process ID = jedineˇcné cˇ íslo procesu

PID PPID

Parent Process ID = Rodiˇcovský PID

RAM

Random Access Memory = pamˇet’ s libovolným (náhodným) pˇrístupem

SSH

Secure Shell = protokol klient/server v síti TCP/IP System GID = bit který rˇíká, že programy bˇeží s právy skupiny programu

SGID

(pokraˇcování na další stránce)

63

(pokraˇcování použitých zkratek)

SUID

System UID = bit který ˇríká, že programy bˇeží s právy vlastníka programu

TCP/IP

Protokolová architektura definovaná sadou protokol˚u pro komunikaci v poˇcítaˇcové síti.

TFTP

Trivial File Transfer Protokol = jednoduchý protokol pro pˇrenos soubor˚u, obsahující jen základní funkce protokolu FTP

UID

User ID = Uživatelské ID

UPS

Uninterruptible Power Supply (Source) = nepˇrerušitelný (záložní) zdroj energie (konec výˇctu zkratek)

64

Návod na p°ipojení k NIS Clinicom Po vložení vypáleného iso souboru, jej vložíme do poˇcítaˇce a nabootujeme. Máme zde na výbˇer mezi 6 volbami: • Slax graficky mod Xwindow a KDE • Slax se souborem trvalych zmen /slax/slaxsave.dat • Slax textovy rezim • Slax graficky mod - nakopirovani do RAM • Slax graficky mod failsafe VESA mod (1024 x 768) • Run memtest utility Jelikož budeme používat pouze pˇripojení z textového terminálu, vybereme Slax textovy rezim. Po nastartování Slaxu do textového terminálu, jsme vyzváni k zadání loginu root, a hesla toor. Jestliže používáme dynamické pˇridˇelování ip adresy, je tato adresa automaticky nastavena a pˇrejdeme proto k poslednímu kroku. Jinak použijeme pˇríkaz netconfig, kde zadáme název poˇcítaˇce (hoste name), název sítˇe (domane name) a v menu vybereme statické nastavení ip adresy. Zde postupnˇe vyplníme ip adresu, masku, bránu a adresu DNS server. Posledním krokem je již spuštˇení programu ssh_clinicom z pˇríkazové ˇrádky. Jsme vyzváni k potvrzení RSA klíˇce - yes a zadání hesla pro uživatele cl, které je cl. Nyní již vybereme typ terminálu 9, tj. vt320 a zde se již pˇrihlásíme svým uživatelským jménem a heslem ke Clinicomu.

Obsah p°iloºeného CD Pˇriložené CD obsahuje 3 adresáˇre: 1. Práce - obsahuje diplomovou práci ve formátu pdf 2. Slax - obsahuje iso soubor i s modulem, který se zavede pˇri startu systému 3. Skripty - tento soubor obsahuje všechny mnou vytvoˇrené skripty, vˇcetnˇe jejich umístˇení na serveru

65

Hardwarová realizace. systému

Recommend Documents