A fázis 1-es végpont megjelenésének hatása a Nyugat-Magyarországi Egyetem soproni hálózatára
(bővített változat)

Az előadás a Nyugat-Magyarországi Egyetemi Soproni Egyetemi Karainak (volt Soproni Egyetem) Informatikai fejlődését követi nyomon néhány éven át, abban az időszakban, amikor a fázis 1-es végpont megjelent Sopronban.

Tartalomjegyzék

1    A Nyugat-Magyarországi Egyetem Informatikai Központjának és informatikai infrastruktúrájának fejlődése. 3

1.1    Egyetemi gerinchálózat korszerűsítése. 3

1.2    Külső telephelyek bekapcsolása BreezeNET eszközzel 4

1.3    Laborok fejlesztése. 5

1.4    A fázis 1-es végpontnak helyet adó szerverszoba kiépítése. 6

1.5    Jövőbeni fejlesztési tervek (Gigabit sebességű gerinc, a VLAN támogatás bővítése) 7

2    A fázis 1-es végponthoz csatlakozó intézményi hálózat megteremtése Linux alapú eszközökkel 9

2.1    A Linux host-ok felépítésének alapja: a /usr/local/LOCALHOST könyvtár 9

2.2    Néhány említésre méltó módon megvalósított funkció. 10

2.2.1  Gigabit sebességű (interfészeken történő :-) gateway működés 10

2.2.2  Iproute2 alapú NAT. 11

2.2.3  BGP kommunikáció a Zebra programcsomaggal 12

2.2.4  NTP alapú rendszeridő-szinkronizálás 13

2.2.5  Az egyetemi levelezőrendszer on-demand vírusvédelme. 13

3    Az Informatikai Központ számítógépes laborjainak, és az összes tanszéki hálózatnak a központi üzemeltetésére kidolgozott rendszer 15

3.1    Az egyetem levelezőrendszerét, a honlap adatbázisát és a laborok SaMBA alapú Windows NT tartományát integráló, weben keresztül menedzselhető rendszer 15

3.2    Hatékony telepítés Symantec Ghost programcsomaggal 15

3.3    A Windows kliensek NTP szinkronizálása a Linux szerverekhez 16

3.4    A munkaállomások általános vírusvédelme VirusBuster rendszerrel 16

4    Dióhéjban az egyetemi honlap fejlesztéséről (http://www.nyme.hu). 18

4.1    Az egyetemi honlap adatbázisának a Neptun-rendszer adatbázisából történő táplálása. 18

4.2    Az Alkalmazott Művészeti Intézet hallgatói által tervezett arculat 18

1         A Nyugat-Magyarországi Egyetem Informatikai Központjának és informatikai infrastruktúrájának fejlődése

1.1        Egyetemi gerinchálózat korszerűsítése

1998 közepén a Nyugat-Magyarországi Egyetem soproni egyetemi karainak - akkor ezeket együtt még Soproni Egyetemnek hívták - Informatikai Központjában átmenetileg három hallgató látta el a rendszergazdai teendőket. Az egyetem belső gerinchálózata még az ezt megelőző időben épült, és egyrészt senki nem dolgozott az Informatikai Központban, aki akár a topológiáját ismerte volna, másrészt az akkor még 10Mb/s sebességű ethernet hálózat felépítéséből adódóan olyan nagy késleltetési idők is felléptek néhány egymástól távol eső végpont között, amelyek adatvesztést is okozhattak, hiszen a hálózat gerince is HUB-okból állt. A jelenlegi rendszergazdai stáb első tagjai ekkor - 1998 közepén – álltak munkába, ezért a korábbi időkből csak írásos emlékek maradtak fenn, ezek azonban kevés információt tartalmaznak, és ennek az információnak is nagy része jelentőségét vesztette. A gerinchálózat modernizálását pénzhiány hátráltatta, ráadásul 1999 októberében és novemberében többször működésképtelenné vált a topológia középpontjában elhelyezkedő Gandalf típusú HUB. Először nagy költséggel Budapesten javítottuk meg, később azonban kiderült, hogy az egyetem rendelkezik egy olyan szakemberrel, aki rendkívül olcsón és rövid idő alatt képes helyben elvégezni a javítást:

A központi HUB többszöri meghibásodása után az egyetem vezetése az Informatikai Központ nyomására szerencsére úgy döntött, hogy az eszköz lecserélésén kívül a gerinchálózat ekkor már igencsak időszerű korszerűsítéséhez is elegendő anyagi keretet biztosít.

Az új hálózat koncepcióját az EIK dolgozta ki külső szakértők segítségével oly módon, hogy a hálózat megépítésére több cégtől kértünk árajánlatot, és a cégek észrevételeit figyelembe véve, a cégekkel konzultálva kölcsönösen finomítottuk a megépítendő hálózat tervét és az árajánlatokat. A beérkezett árajánlatoknak a kivitelezés költségeit, a kivitelezéshez kapcsolódó szolgáltatásokat és a technikai tartalmat figyelembe vevő elbírálása során a budapesti SCI-NetWork Rt. tervét találtuk a legmegfelelőbbnek, így a kivitelezés jogát ez a cég nyerte el. A hálózatfejlesztés első fázisa 1999. december 22-én, 23-án és 2000. január 7-én, 8-án zajlott.

A megépített hálózatban a gerinchálózati topológia központi HUB-ját és az első szinten hozzá csatlakozó HUB-okat 100Mbit/s-os switch-ekre cseréltük, így az új hálózat a korábbi egyetlen ütközési tartomány helyett sok tartományra szakadt (igaz, ekkor még mindig egyetlen broadcast tartomány volt), és minden épületközi üvegszálas kapcsolat valamint az Egyetemi Informatikai Központ által gondozott linkek nagy része full duplex forgalmat tesz lehetővé, ezáltal tovább növelve a hálózat elemeinek hatékonyságát. A hálózat több ütközési tartományra történő szeparálása a régi hálózat legnagyobb hibái között említett adatvesztési lehetőséget is megszüntette.

Annak ellenére, hogy ekkorra a gerinchálózat elfogadható megbízhatósági- és teljesítménybeli jellemzőkkel rendelkezett, az Internet-elérésünk sávszélessége még messze elmaradt attól, hogy képes legyen kielégíteni az igényeket. Ebben az időben a HBONE soproni végpontja még nem a Soproni Egyetemen kapott helyet, hanem a MTA soproni Geofizikai Kutatóintézetében. Az egyetem intézményi hálózatát egy Cisco 2501-es eszköz kötötte össze az Internettel, amely előbb 64kb/s-os, később 128kb/s-os bérelt vonalon keresztül kapcsolódott a Geofizikai Kutatóintézet hálózatához. Ekkor még nem is folyt közvetlen kommunikáció az NIIF és a Soproni Egyetem Informatikai Központja között, sőt nekünk, rendszergazdáknak az első időkben még az NIIF létezéséről sem volt tudomásunk. Az egyetem vezetősége és az Informatikai Központ 2000-ben vette fel a kapcsolatot az NIIF-fel, akiktől azt kértük, hogy a HBONE soproni végpontja kerüljön az - ekkor már Nyugat-Magyarországi Egyetem névre hallgató - egyetemre, arra hivatkozva, hogy itt több ezer, míg a Geofizikai Kutatóintézetben csak néhányszor tíz ember használja az Internetet. Az NIIF döntése értelmében a HBONE hálózat fejlesztésének azon szakaszában, mikor a 155Mb/s sebességű budapesti kapcsolattal rendelkező Fázis 1-es végpontok és a 34Mb/s sávszélességgel a Fázis 1-es végpontokhoz csatlakozó Fázis 2-es végpontok kiépítésre kerültek, a Nyugat-Magyarországi Egyetem soproni campusára Fázis 1-es végpont került! A 155Mb/s sávszélességű budapesti STM-1-es kapcsolatot kezelő Cisco 4700-as NIIF router egy fast ethernet interfésze teljes egészében az egyetem rendelkezésére állt, így a 128kb/s-os Internet-kijárati sávszélesség ugrásszerűen csaknem 800-szorosára nőtt. Az Internet-elérés sebességének drasztikus növekedése, de még inkább az NIIF és az egyetem között létrejövő jó kapcsolat és a Fázis 1-es végpontnak az egyetemen történő elhelyezése az informatikára irányította az egyetem vezetésének figyelmét, és ettől az időtől fogva az Informatikai Központ anyagi és erkölcsi értelemben véve is fokozatosan javuló feltételek között végezhette az informatikai infrastruktúra fejlesztését.

1.2        Külső telephelyek bekapcsolása BreezeNET eszközzel

A Nyugat-Magyarországi Egyetem soproni egyetemi karainak kezdetben minden intézménye egyetlen telephelyen, a botanikus kert területén helyezkedett el, így az itteni ethernet gerinchálózat mindenki számára biztosította az Internet-elérést. Az intézmény növekedése folytán azonban néhány intézet, kar és kollégium a városban újonnan vett vagy bérelt épületekbe költözött, amelyek a botanikus kerttől távol helyezkednek el. Az Internetet egy ideig ISDN előfizetések segítségével érték el, azonban felmerült az igény folyamatosan élő és nagyobb sebességű kapcsolatok létesítésére. Több céggel folytattunk tárgyalásokat, míg végül a budapesti SCI-NetWork Rt. által javasolt BreezeNET DS.11 eszközökkel létesítendő 11Mb/s sebességű rádiófrekvenciás kapcsolatok mellett döntöttünk. A 2,4GHz-es szabad frekvenciát használó BreezeNET eszközök ára ugyan viszonylag magas, azonban robosztus tervezésükből és nagy adóteljesítményükből adódóan gyakorlatilag fennakadás nélküli kapcsolatot biztosítanak szinte bármilyen időjárási és elektromágneses zavaró hatás ellenére. Hálózati szempontból a BreezeNET DS.11 IEEE 802.11b rádiós hálózaton átívelő IEEE 802.3 (ethernet) bridge-ként működik. A kiépült BreezeNET kapcsolatok négy városi telephelyet kötnek össze a központi campussal. A négy telephely közül három, a Baross úti kollégium, az Erzsébet utcai Közgazdaságtudományi Kar és a Deák téri Alkalmazott művészeti intézet épülete közvetlen rálátással rendelkezik a botanikus kertben elhelyezkedő legmagasabb épületre, az új kollégiumra, ezért ezek irányított antennapárral megvalósított közvetlen kapcsolattal rendelkeznek. A negyedik külső intézet, az Idegennyelvi Központ antennája az Alkalmazott Művészeti Intézet épületére irányul.

A soproni telephelyek elhelyezkedését a következő ábra szemlélteti:

A rádiós átvitel a nála jóval nagyobb sebességű ethernet hálózatba betoldva szűk keresztmetszetnek számít, ráadásul az egyes rádiófrekvenciás kapcsolatoknak mindkét oldalán viszonylag nagy méretű ethernet hálózati szegmensek vannak. Szinte elengedhetetlen, hogy a BreezeNET adóvevő eszközök a hálózattól mindkét oldalon layer 3-as eszközzel legyenek leválasztva, amelyek az alacsony sebességű rádiós szegmensbe nem engedik be a nélkülözhető csomagokat, pl. a Netbios protokoll vagy a Ghost programcsomag broadcast üzeneteit. Az új kollégium tetején létesült BreezeNET átjátszóközpontban a layer 3-as elválasztást egy layer 3 modullal bővített 3Com SuperStack 3 3300 típusú switch végzi. A linkek túloldalán levő négy épület közül jelenleg csak az Erzsébet utcai Közgazdaságtudományi Karon van egy Linux alapú router az antenna mögött.

1.3        Laborok fejlesztése

2001 elejéig az Informatikai Központ két laborban összesen 22 számítógépet üzemeltetett, mindegyik számítógépen Windows NT 4.0 operációs rendszert futtattunk. Az Informatikai Központ alkalmazottai között oktatók is vannak, a soproni egyetemi karokon ők végzik az általános informatikai oktatást, de természetesen az egyetem többi tanszéke is tarthat órákat a laborokban, ha pedig az órarend szerint szabad egy labor, azt az egyetem hallgatói korlátozás nélkül használhatják.

2001-ben az összes addig használt munkaállomást leselejteztük. Jelenleg már 67 darab új számítógép áll a hallgatók rendelkezésére öt laborban. Az új számítógépek közül huszonhetet a Faipari Kar nyert az Oktatási Minisztérium pályázatain az azóta már beindított informatikai képzés, és a közeljövőben létesítendő Informatikai Kar részére. A fennmaradó 40 számítógépet 2002-ben az Informatikai Központ pályázta meg az NIIF program ClusterGrid projektjének keretében.

A korábban használt két labor az Informatikai Központ irodái mellett helyezkedett el a központi B épületben. Itt továbbra is két laborunk van, mert igaz ugyan, hogy egyet felszámoltunk az újonnan létesített 2,5Gb/s sebességű Fázis 1-es végpont kedvéért, de sikerült egy addig üresen álló helyiséget laborként üzembe helyezni.

A többi számítógép elhelyezését úgy oldottuk meg, hogy időközben az egyetem használatra átvett egy új épületet, amely a botanikus kerttel szemben helyezkedik el, és az utca alatt lefektetett üvegkábelekkel sikerült ide is kiterjeszteni az egyetem gerinchálózatát. Az új épületben hozzávetőlegesen 100 végpontot létesítettünk. Négy számítógéplabort hoztunk létre, amelyből egyelőre hármat töltöttünk fel munkaállomásokkal.

A számítógépeken kivétel nélkül Windows 2000 Professional-t futtatunk egyetlen közös pre-Windows 2000 tartományba szervezve őket, amelynek egy Linux alatt futó SaMBa szerver az elsődleges tartományvezérlője. Mivel ez a tartomány integrálva van az egyetem központi levelezőrendszerével, minden dolgozó és hallgató, aki hivatalos egyetemi e-mail címmel rendelkezik, bármelyik gépre beléphet a saját nevével. A felhasználók központi profillal rendelkeznek, a Windows-os beállításaik minden gépen megegyeznek, és mindenhonnan elérhetik a UNIX-os home-könyvtárukat, mint csatlakoztatott hálózati meghajtót. A rendelkezésükre áll egy nagyméretű (15GB) közös tárterületet is, melynek segítségével fájlokat oszthatnak meg egymás között, vagy átmenetileg nagyobb fájlokat tárolhatnak rajta.

Ezen erőforrásokon, és a nagysebességű Internet-elérésen kívül a hallgatók rendelkezésére áll egy A0-ás méretű poszternyomtató, amely műszaki rajzok plottolására kiválóan alkalmas, egy nagyteljesítményű fekete-fehér kombinált nyomtató és fénymásoló, egy nagy- és egy kisebb teljesítményű színes nyomtató, valamint két szkenner.

1.4        A fázis 1-es végpontnak helyet adó szerverszoba kiépítése

Amikor a soproni Fázis 1-es végpontot a budapesti központtal összekötő vonal sávszélessége 155Mb/s volt, a soproni NIIF hálózati eszközök számára az egyetem telefonközpontjában biztosítottunk helyet. Ez a helyiség nem volt kifejezetten szerverszobává kiképezve, csak légkondícionálással láttuk el, de magasabb szintű pormentességi, tűz- és behatolásvédelmi követelményeknek nem felelt meg. Amikor eldőlt, hogy a HBONE Fázis 1-es végpontjainak sávszélessége 2,5Gb/s-ra nő, és több új nagy értékű NIIF berendezést kell elhelyezni, világossá vált, hogy nem használhatjuk tovább a telefonközpont helységét HBONE szerverszobaként, már csak a mérete miatt sem.

Egy új szerverszoba kialakítását határoztuk el egy akkor még hallgatói számítógéplaborként funkcionáló helységben, amely ugyan távol volt a Matáv egyetemi SDH végberendezésétől, viszont itt volt az egyetemi gerinchálózat csillag alakú topológiájának középpontja, egy HP Procurve 4000M switch formájában.

Az új szerverszoba kialakításához ki kellett üríteni a termet, felszedni a padlót, sőt, mivel korábban egy röntgen laboratórium volt a terem alatti alagsori helységben, több száz kg ólomlemezt is felszedtünk a padlózat betonburkolata alól. Az antisztatikus álpadló beszereléséhez új, teljesen vízszintes és sima betonréteget öntöttek a régi helyére. Az ablakokat végleg lezárták, szigeteléssel és törésvédő fóliákkal látták el. A falak pormentes tapétaburkolatot kaptak, álmennyezet került kiépítésre. Elhelyezésre került egy automatikus tűzérzékelő, egy behatolásérzékelő, egy kártyás beléptetőrendszer, valamint egy split elven működő redundáns klimatizálórendszer. A szerverszoba számára az egyetem villamos rendszeréről új, folyamatos energiaellátást biztosító vonalakat vezettettünk be, és a helyiség rack-szekrényei és a konnektorok egy része nem közvetlenül erről kapják a betáplálást, hanem egy 3x20kW teljesítményű APC Silcon szünetmentes tápegységről. A helységben új rack-szekrényeket helyezett el mind az egyetem, mind az NIIF. A végpont üzembe helyezéséhez szükség volt az egyetemi gerinchálózat összes központi linkjének átrendezésére, valamint a Matáv tulajdonú SDH infrastruktúra üvegszálainak az alagsoron keresztüli bevezetésére.

A szerverszoba kiépítésével kapcsolatos költségeket az egyetem gazdasági vezetősége állta. A költségek csaknem elérték a húszmillió forintot.

A szerverszoba kiépítésének kezdete:

A szerverszoba üzem közben:

1.5        Jövőbeni fejlesztési tervek (Gigabit sebességű gerinc, a VLAN támogatás bővítése)

A soproni egyetemi karok informatikai infrastruktúrájában sok fejlesztést hajtottunk végre. Van néhány olyan fejlesztési feladat, amelyeket lehetőség szerint minél hamarabb végre kell hajtanunk. A legfontosabb ilyen feladatok vázlatosan felsorolva:

2         A fázis 1-es végponthoz csatlakozó intézményi hálózat megteremtése Linux alapú eszközökkel

2.1        A Linux host-ok felépítésének alapja: a /usr/local/LOCALHOST könyvtár

A soproni egyetemi karok intézményi hálózatának minden jelentősebb központi szerverén SuSE Linux disztribúciókat futtatunk. A legfrissebb hiba- és biztonsági javításokat tartalmazó új programcsomagok letöltéséről a fou4s (http://fou4s.gaugusch.at) szoftver gondoskodik.

Egy ízben előfordult, hogy az egyik szerverünk crackerek támadásának esett áldozatul, és olyan programokat telepítettek fel rá, amelyek a felhasználók begépelt jelszavait ellopták, majd e-mail-ben elküldték a betörőknek: Ezenkívül lecserélték a System V indítórendszerből a hálózati alrendszer szkriptjeit, és más programokat, amelyek segítségével az egész csomag megpróbált láthatatlanná válni. Mivel azonban az „illegális” system V szkriptek nem jól illeszkedtek az operációs rendszerhez, elárulták az egész csomagot. A programok rejtőzködő voltából adódó nem tudtuk teljesen körülhatárolni a behatolás által érintett területeket, ezért nem mertünk megpróbálkozni a szerver betörés előtti állapotának visszaállításával, hanem újratelepítettük az egészet.

A hasonló okokból, a disztribúciók nagyobb verzióváltásából, esetleg hardver hibából, vagy bármilyen más okból szükségessé váló újratelepítések esetére kidolgoztunk egy olyan módszert, amely megkönnyíti a szerverek funkcióihoz tartozó konfigurációs adatok és egyéb hasznos információk áttekinthető csoportosítását, biztonsági mentését, hatékony tárolását és átvitelét a régi rendszerből a frissen telepített újra.

Olyan módszert próbáltunk kidolgozni, amelynek segítségével koncentráltan és áttekinthető módon tudjuk tárolni azt az információt, amelyet egy frissen telepített, konfigurálatlan Linux disztribúcióhoz hozzáadva előáll az eredeti szerver minden funkcionalitása. Ezen követelményekre válaszként egy olyan megoldást dolgoztunk ki, amelynek alapja egy LOCALHOST nevű alkönyvtár a /usr/local könyvtárban. A /usr/local/LOCALHOST könyvtárat központi konfigurációs könyvtárnak neveztük el, felépítése pedig a következő:

Ha egy konfigurációs fájlt megváltoztatunk a rendszeren, előbb megnézzük, hogy melyik RPM csomaghoz tartozik. A központi konfigurációs könyvtárban létrehozunk egy alkönyvtárat, amely az adott csomag nevét viseli, ebben elmentjük a még módosítatlan konfigurációs fájt úgy, hogy a nevéhez hozzáadjuk a .SYSSAVE kiterjesztést, majd ugyanitt létrehozunk egy másolatot erről a fájról az eredeti nevével, ebben elvégezzük a szükséges módosításokat olyan kommentezéssel, hogy később minden megváltoztatott paramétert könnyen és gyorsan megtalálhassunk szövegszerkesztővel, végül az eredeti helyen található konfigurációs fájlt letöröljük, a helyére pedig egy szimbolikus linket teszünk, amely a központi konfigurációs könyvtárban levő módosított változatra mutat. Ha a rendszerre olyan szoftvert telepítünk, amely nem a disztribúcióból származik, akkor ennek a lefordítatlan forrását is elhelyezzük a központi konfigurációs könyvtár src alkönyvtárában. A központi konfigurációs könytár tartalmaz továbbá három szkriptet is. Mindhárom szkript általában csak akkor tölti be a teljes feladatkörét, ha az egész könyvtárat egy frissen telepített rendszerre másolva be kell üzemelni.

Az első szkript (confsve.sh) automatikusan elvégzi a módosítandó konfigurációs fájlok fentebb leírt .SYSSAVE kiterjesztést is hozzáadó mentését, és elment egyéb automatikusan nem felhasználható rendszeradatokat is, pl. a partíciók kiosztását, a feltelepített RPM csomagok listáját, a rendszerre telepített MySQL és egyéb adatbázisokat a központi konfigurációs könytár megfelelő alkönyvtárába dumpolja, stb.

A második szkript (confreplace.sh) a fentebb leírt módon a központi konfigurációs könyvtárban található módosított konfigurációs fájloknak az eredeti módosítatlan fájlok helyére történő linkelését - vagy ha a fájlra a /usr fájlrendszer mountolása előtt is szükség van, akkor a másolását - végzi el, ezen felül ha szükséges és lehetséges, akkor lefordítja és telepíti a disztribúción kívülről származó programcsomagokat.

A harmadik szkript (confrestore.sh) az elmentett .SYSSAVE fájlokat felhasználva képes a disztribúció eredeti, funkció nélküli állapotának visszaállítására.

2.2        Néhány említésre méltó módon megvalósított funkció

2.2.1      Gigabit sebességű (interfészeken történő :-) gateway működés

A soproni HBONE POP 2,5Gb/s sebességre történő átállása kapcsán lehetővé vált, hogy az intézményi hálózatot gigabit sebességű ethernet interfészen keresztüli csatlakoztatassuk a HBONE felé. Ekkor még nem állt a rendelkezésünkre megfelelő teljesítményű layer 3-as hálózati eszköz, és a HBONE-hoz fast ethernet interfészen keresztül csatlakoztunk egy Linux alapú router segítségével, amely csomagszűrést és többfajta NAT-ot is végzett, valamint HTTP proxyt futtatott. A gigabit sebességű kijárat kiaknázásához új eszközre volt szükségünk. Választanunk kellett célhardver (Cisco router) vagy szoftveres eszköz (PC alapú Linux router) beszerzése között. Végül az anyagi forrásaink korlátozott volta miatt az utóbbira esett a választás. Azért mertünk a Linux mellett dönteni, mert egy svéd-norvég-finn UNINETT projekt keretében végzett méréssorozatra akadtunk az Interneten, melynek tanúsága szerint megfelelő PC kompatíbilis hardver architektúrán futtatva a Linux TCP/IP forgalmazóként és routerként egyaránt képes a gigabit sebesség elérésére. Az UNINETT projekt keretében lejegyzett mérési eredmények megtalálhatók a http://www.uninett.no/tcp-revisited/gigabit.html oldalon. A kísérletben szereplő hardverhez képest kicsit nagyobb teljesítményű Intel alapú szervert vásároltunk, nevezetesen egy IBM Eserver xSeries 232 szervert 1,3GHz-es Pentium III processzorral, 1280MB RAM-mal, és két darab fast/wide PCI buszos (64bit x 66MHz) gigabit ethernet hálózati kártyával. Ezen paraméterek alapján a rendszernek könnyedén le kellene adnia a gigabites teljesítményt, azonban az egyetemi tűzfal szerepét betöltő eszköznek az egyszerű route-olásnál összetetteb feladatokat kell ellátnia, pl. viszonylag nagy ARP táblával és sok TCP/IP kapcsolattal kénytelen dolgozni. Bonyolult NAT és csomagszűrési műveleteket végez, transzparens proxyként működik, BGP kommunikációt bonyolít le, stb. A kernel TCP/IP rendszerének vezérlését egy saját fejlesztésű router/tűzfal szkriptrendszer végzi, amelyet a régi fast ethernet gateway-ről hoztunk át néhány változtatással, amelyek közül a legjelentősebb az ipchains rendszerről az iptables-re történő átállás volt.

A gigabit sebességű interfészek kihasználásának optimalizálása érdekében mértük a hálózati kártyák kimenő és bejövő forgalmát és a CPU terhelését. A méréseket másodperces periódusú mintavételezéssel végeztük, amit SNMP-vel nem tudtunk megcsinálni. Közvetlenül a /proc fájlrendszerből gyűjtöttük CSV táblázatba az adatokat egy shell szkript segítségével. A táblázatokból OpenOffice.org és Excel segítségével diagramokat rajzoltunk. Kitűnt, hogy a mérési módszer nem teljesen pontos. Minden valószínűség szerint azért, mert a rendszer terhelésével arányosan kicsit megnő a mintavételi intervallum, de a mérési eredmények korrekció nélkül is jól értelmezhetőek. (Igaz, 100% feletti CPU terhelés is látható az ábrákon.) Az eredményekből okulva optimalizáltuk a gateway működését a következő rendszerparaméterek megváltoztatásával:

A CPU-terhelésnek egyébként nem elhanyagolható hányada a squid HTTP proxy szerver üzemeltetéséből adódik, de nem szeretnénk lemondani róla, mert ez lehetővé teszi a webforgalom alkalmazás szinten történő szűrését. A méréseket élesben végeztük, a rendszert nem tesztprogramokkal, hanem valós alkalmazásokkal terhelve.

A legnagyobb mért adatátviteli sebességhez tartozó diagram a következő ábrán látható:

A ábrázolást sajnos csak időtartományban tudtuk megvalósítani, de ebből is le lehet vonni a következtetést, hogy nem sikerült elérni az 1Gb/s átviteli sebességet. Mindenesetre az internetezés szubjektív érzete folyamatosan tökéletes, és a gateway az üzembehelyezése óta fennakadás nélkül működik. A jövőben a hardver- és szoftver konfiguráció módosításával, fejlesztésével tovább próbáljuk növelni a teljesítményt. Minden jel arra mutat azonban, hogy egy több nagysebességű interfésszel rendelkező, dinamikusan töltött nagyméretű routing táblával dolgozó gateway megvalósítása PC architektúrával valószínűleg nem lehetséges.

2.2.2      Iproute2 alapú NAT

Kezdetben a soproni egyetemi karok intézményi hálózatában a TCP/IP kommunikációt folytató számítógépek IP címeit egyetlen nyilvános C osztályú tartományból osztottuk ki. Mivel a gépek számának gyarapodása folytán ezt az utolsó címig kihasználtuk, még egy C tartományt igényeltünk. Később az intézményi hálózat elkezdett a városban terjeszkedni, és mivel a különböző telephelyeken levő szegmenseket szűk keresztmetszetű BreezeNET rádiófrekvenciás linkek kötik össze, szükségessé vált a layer 3-as szinten történő megosztás. Ha ezt pusztán a meglevő két C osztály feldarabolásával értük volna el, nem maradt volna minden telephely számára elegendő cím, ezért úgy döntöttünk, hogy a munkaállomások privát IP címeket kapnak, még a már kiosztott nyilvánosakat is elvesszük tőlük. A nyilvános címeket kizárólag a szerverek számára tartjuk fenn. Az Új Kollégium magas épületének tetején - ahova az összes BreezeNET kapcsolat befut -, egy layer 3 switch-csel a hálózatot hat szegmensre vágtuk szét. Ezek mindegyike egy privát B osztályú IP címtartományt kapott 172.16.0.0-tól 172.21.0.0-ig. A címeket statikusan osztjuk ki, pl. 172.16.x.y formában. Az x változóba egy olyan kódszámot helyettesítünk be, amely a számítógépet birtokló szervezeti egységet egyértelműen azonosítja. Az új, kisebb broadcast tartományok némelyikén sajnos együtt létezik egymás mellett a munkaállomások privát IP címtartománya a  szerverek nyilvános C osztályával. Hogy a helyzet egy kicsit még tovább bonyolódjon, néhány szervezeti egység saját Linux alapú routerrel leválasztott 192.168.x.0 privát IP címtartománnyal gazdálkodik.

Az intézményi hálózatok IP címtartományai mind egyszerű route-olással kapcsolódnak egymáshoz, legfeljebb csomagszűréssel korlátozva. A külvilág felé azonban természetesen nem továbbíthatjuk ilyen módon a privát címtartományból érkező csomagokat, ezért ezeket masquerade-olásnak veti alá az intézményi tűzfal. Felmerült az igény kívülről is elérhető szerverek üzemeltetésére néhány olyan hálózati szegmensben is, ahol csak masquerade-olt IP címek vannak, és nyilvános IP cím kiadását még a jövőben sem tervezzük. Hogy ezek a privát IP címmel rendelkező szerverek elérhetőek legyenek a külvilág felől is, azt NAT-olással tettük lehetővé, amelyet szintén az intézményi tűzfal végez. A tűzfal a szóban forgó szerverek valódi privát IP címéhez egy nyilvános IP címet rendel. Ha a külvilág felől erre a nyilvános IP címre küldött csomag érkezik, akkor a célcímet lecseréljük a privát IP címre vagyis DNAT-ot hajtunk végre. Ha pedig a privát IP címmel rendelkező szerver a külvilág felé küld IP csomagot, akkor a forráscímet cseréljük le a megfelelő nyilvános IP címre, vagyis SNAT-ot hajtunk végre. Mivel ilyen összetett csomagkezelésre van szükség az intézményi hálózat és a HBONE határán, ezért az intézmény Linux alapú tűzfalán saját magunk által írt hálózati szkriptrendszert futtatunk, amely nagyrészt az iptables és Iproute2 programcsomagokra épül.

A Linux kernelben működő NAT rutinokba általában a csomagszűrő rendszerek (ipfwadm, ipchains, netfilter) táplálják bele a manipulálandó IP csomagokat. Ezt a feladatot elvégezhetjük a policy router-rel is, amelyet az Iproute2 programcsomaggal vezérelhetünk. A policy router funkció az advanced router-ként lefordított Linux kernel egyik opcionális szolgáltatása, amely a 2.2-es verzióktól elérhető. Korábban a kernel egyetlen routing táblát használt. A célprefix/TOS/metric hármas kulcs segítségével ebből választotta ki a legmegfelelőbb utat az elküldendő IP csomagok számára. Policy routerként működve 256 ugyanilyen routing tábla áll a rendszeradminisztrátorok rendelkezésére. Egy újonnan megjelent táblázat segítségével választja ki a kernel, hogy melyik routing táblából kutassa ki az adott csomagok célját. Ez az új táblázat a "routing policy database" vagy RPDB ún. ip rule-okból áll, amelyeken a netfilter bejegyzésekhez hasonlóan meghatározott sorrendben jár végig a kernel. Ha valamelyik ip rule által megadott routing tábla képtelen az adott IP csomag kézbesítésére, akkor nem dobja el a csomagot, hanem megvizsgálja a következőt. Az ip rule-ok összetetteb feltételek alapján képesek megvizsgálni az IP csomagokat, mint a hierarchiában alattuk álló route-ok. Például képesek olyan metainformációk vizsgálatára, mint a netfilter jellegű szűrőrendszerek által a csomagokra rakott jelzőcímke. Érdekes módon a DNAT és SNAT műveleteket indikáló utasítások különböző helyen vannak. DNAT műveleteket az egyes routing táblák segítségével lehet megadni, SNAT műveleteket pedig az RPDB-be helyezett megfelelő rule-okkal.

A policy routert magába foglaló advanced router rendszer még sok hasznos extra képességgel rendelkezik a korábbi egyszerű router funkcióhoz képest, pl. IP tunnel-ek létrehozását teszi lehetővé. Az advanced router vezérlésére szolgáló Iproute2 programcsomag kiváló - bár néhány finomságot nem említő - dokumentációját megtalálhatjuk a http://www.linuxgrill.com/iproute2-toc.html címen.

2.2.3      BGP kommunikáció a Zebra programcsomaggal

Az Internetet a hálózatok hálózataként is emlegetik. Ebből a szempontból nézve egy-egy hálózat egy IP címtartománynak felel meg, és ezek a tartományok egy vagy több gateway-en keresztül kapcsolódnak egymáshoz. Minden gateway-en keresztül egy vagy több IP címtartomány érhető el. A közös adminisztráció alatt álló (pl. ugyanazon szervezet vagy cég által birtokolt), ezért általában a hálózati infrastruktúrában is szorosabban egymáshoz kötődő IP címtartományokat autonóm rendszerekbe, ún. AS-ekbe szervezik. Az egy vagy több IP címtartományt birtokló természetes vagy jogi személyek az IP címekéhez hasonló adminisztráció útján igényelhetnek AS azonosító számot, amely ebből kifolyólag ugyanúgy egyéni, mint maguk az IP címtartományok. Az Interneten az AS-ek határán levő routerek (border gateway-ek) egymás között a BGP protokollal kommunikálnak, így képesek a routing tábláikat úgy feltölteni, hogy az IP csomagokat akár a legtávolabbi számítógéphez is optimális útvonalon juttassák el. Nagy vonalakban elmondható, hogy a BGP protokoll az Internet az egymáshoz kapcsolt AS-ekből álló gráfként látja, de az egyes AS-ek belső szerkezetével nem foglalkozik, számára az csak IP címtartományok halmaza. A BGP használatára többnyire csak olyan AS-ekben (intézményi hálózatokban) van szükség, amelyek több külső összeköttetéssel rendelkeznek, ilyen esetekben ugyanis, hogy ne egy gataway-en keresztül menjen az összes külső forgalom, nem elég egy default route-ot megadni, hanem az AS határain levő border gateway-ek a BGP protokoll segítségével bonyolult routing táblákat állítanak össze saját maguk, egymás és a hálózaton belüli routerek részére, hogy minden külső célponttal az optimális úton keresztül létesíthessen kapcsolatot a hálózat.

A Nyugat-Magyarországi Egyetem soproni egyetemi karainak intézményi hálózata egyetlen kijárattal rendelkezik, ezért a világ felé egyetlen statikus default route mutat. Ebben a szituációban az intézményi hálózat működése szempontjából nézve a BGP protokoll használata értelmetlen. Az NIIF azonban megkért minket arra, hogy a soproni HBONE POP routerével lépjünk BGP kapcsolatba. Ennek az a haszna, hogy mivel az intézményi hálózat IP címtartományait az intézmény saját routere hirdeti a HBONE-on keresztül a világ felé, az NIIF-nek nem kell az intézményi IP címek struktúrájára vonatkozó adminisztrációt végeznie a BGP adatbázisban. Ha az intézmény által használt IP címekben változás áll be, azt elegendő helyileg bejegyezni, és a „hír” így is automatikusan elterjed a világban. Az egyetemi hálózat számára nem igényeltünk AS-t, hanem a privát IP címek analógiájára privát AS azonosítót használunk, amelyet a világ felé a HBONE routere masquerade-ol oly módon, mintha az egyetem IP címtartományai a HBONE gerinchálózat részét képeznék.

Mivel az egyetemi hálózat egy Linux alapú gateway-en keresztül kapcsolódik a HBONE POP-hoz, a BGP kommunikációt Linux alatt kellett megoldanunk. Erre a célra a Zebra programcsomagot használjuk (http://www.zebra.org), amely a BGP-t is beleértve jelenleg négy routing protokollt támogat. A Zepra projekt alapítója Kunihiro Ishiguro rendkívül nagy tapasztalattal rendelkezik nagy méretű IP hálózatok menedzselése terén. A Zebra moduláris felépítésű: minden routing protokollt külön démon kezel, ezenkívül egy központi zebra démon is fut, amely összefogja az előbbiek működését, és kapcsolatot tart a kernel TCP/IP alrendszerével. A démonok egymás között a Zebra protokollal kommunikálnak. Ez a moduláris felépítés meggyorsítja és problémamentessé teszi az Zebra csomag egyes alrendszereinek fejlesztését. Kizárja a teljes rendszer összeomlását akkor, ha csak egy adott protokoll megvalósítása hibás.

2.2.4      NTP alapú rendszeridő-szinkronizálás

Ahogy az intézményi hálózatban nőtt a szerverek száma, és szembesülnünk kellett néhány kellemetlenséggel, amelyet a számítógépek rendszeridejének egymáshoz és a pontos időhöz képesti eltérése okozott. Úgy döntöttünk, hogy valamilyen pontos idő szolgáltatást veszünk igénybe. E célból szóba jöhet műholdas (GPS), földi rádiós, vagy modemen keresztül elérhető referenciaórához történő időzítés, de létezik internetes megoldás is. Az Internet pontos idő szolgáltató rendszerei közül a legelterjedtebb a már több mint két évtizede folyamatosan működő NTP szabványra épülő infrastruktúra, amely az Interneten bizonyos értelemben az idő de facto szabványának tekinthető (http://www.ntp.org). Az NTP szabványt David L. Mills professzor kezdte fejleszteni a Delaware-i egyetemen. Alapelve, hogy az NTP démont futtató számítógépek nem teljesen szigorú értelemben vett hierarchikus kapcsolatban vannak egymással. A saját referenciaórával rendelkező szerverek szintjét 1. rétegnek (stratum) nevezik, ezen szerverek kliensei a 2. rétegben vannak és így tovább. A pontos idő jelzések annál megbízhatóbbnak minősülnek, minél alacsonyabb rétegből érkeznek. Az NTP rendszerben használt algoritmusokat és a hálózati protokollt RFC dokumentumokban szabványosítják. Jelenleg a negyedek verzió aktuális, ami azonban még nem írásban lefektetett szabvány. A legutolsó NTP-hez kapcsolódó RFC száma 2030, és a négyes számú verzió egyszerűsített változatát, az SNTP protokollt definiálja. Az SNTP kompatíbilis rendszerek egyszerűbb módon kalkulálják a pontos időt, és az NTP fejlesztők eredeti szándéka szerint csak kliensként szabad őket használni, szerverként nem. Az SNTP szabvány egyik megvalósítása az Active Directory alapú Windows tartományok elsődleges tartományvezérlőjén futó Windows Idő szolgáltatás, amelyhez alapértelmezésben a tartomány összes számítógépe szinkronizálja a saját rendszeridejét. Mivel az teljesértékű NTP protokoll legutóbbi - már elterjedt - verziója hivatalosan még nincs szabványosítva, definíciójának a http://www.ntp.org oldalról is letölthető nyílt forráskódú xntp programcsomag tekinthető, amely minden NTP képességgel rendelkezik, és a UNIX szoftverek hagyományához hűen nagymértékben skálázható, de éppen ezért sajnos emberi lények számára nehezen áttekinthető. Teljes körű NTP megvalósítás mivoltából adódóan az xntp rendszer a hálózati hierarchia kialakitásában többféle viszonyt (kliens-szerver, peer to peer), többféle üzenetküldési módot (unicast, broadcast, multicast, unicast), és többféle authentikációs eljárást (titkos- és nyilvános kulcsú algoritmusok, DES, MD5 kulcsok, stb) ismer, és az időkalkulációt befolyásoló algoritmusai is széles határok között variálhatók és skálázhatók.

Az intézményi hálózatban két xntp démont futtató Linux alapú NTP szervert helyeztünk üzembe. Mindkét szerver 6-6, vagyis összesen 12 db 1. vagy 2. rétegbeli NTP szervertől kérdezi le az időt. A szervereket az Interneten keresztül szabadon lekérdezhető szerverek listájából választottuk, amely szintén a http://www.ntp.org oldalon található. A Soproni Egyetemi Karok két NTP szervere az ntp.sek.nyme.hu és az ntp2.sek.nyme.hu nevek alatt érhető el. A két szerver a külső kapcsolatokon kívül egymással is kommunikál peer to peer módban, és referenciaszerverként szolgálnak szinte az összes munkaállomás és szerver számára.

2.2.5      Az egyetemi levelezőrendszer on-demand vírusvédelme

Az egyetem vírusvédelmi rendszerének tervezésekor olyan terméket és licenszelési konstrukciót választottunk, amely lehetővé teszi a levelezőrendszerek védelmét is. A magyar gyártmányú VirusBuster szoftvercsalád tagja, a VirusBuster for LinuxMail program segítségével meg tudtuk oldani az soproni egyetemi karok Linux alapú központi, hivatalos levelezőszerverének védelmét. Ez a termék az AMaViS nevű, levelezőrendszerekhez fejlesztett ingyenes vírusirtó keretrendszerhez készült. Az AMAViS-t a központi Sendmail levelezőszerver bonyolult konfigurációja miatt úgy telepítettük, hogy csak a beérkező leveleket ellenőrizze. Ebben a felállásban a sendmail által eredetileg meghívott helyi kézbesítő ágens, a procmail program helyére az AMAViS megfelelő programját helyezzük be, amely az átvett levelet néhány külső programcsomag segítségével teljesen darabokra bontja. Minden összetevőjét - így a csatolt állományokat is - fájlként kimásolja egy ideiglenes könyvtárba, majd utasítja a vírusellenőrző programot - jelen esetben a VirusBuster-t, hogy ellenőrizze le a teljes könyvtárat. Az antivírus program által adott visszatérési értékből az AMaViS megállapítja, hogy a levél tartalmaz-e vírust. Amennyiben igen, eldobja a levelet, és válaszlevélben figyelmezteti a feladót a vírusveszélyre, valamint a rendszergazdát is értesíti. Ha nem talál vírust a levélben, akkor változatlan formában továbbadja az eredeti helyi kézbesítő ágensnek, amely elhelyezi a címzett postaládájában.

Ennek a védelmi rendszernek, és az óránként automatikusan frissített vírusadatbázisnak köszönhetően elértük, hogy az utóbbi két évben a központi levelezőszerverre érkező levelekből tudomásunk szerint nem kelt ki vírus vagy féregprogram.

A VirusBuster szoftvercsalád Linux alapú levelezőrendszerekhez készült antivírus termékének általunk használt verziója időközben elavult, és kivonták a forgalomból. Az új termék neve VirusBuster MailShield for SMTP. Ennek az új terméknek a fejlesztését teljesen új alapokra helyezték, a működési elvet teljesen megváltoztatták. Az új rendszer már nem az AMaViS-re épül, hanem önálló démonként fut, és széles határok között skálázható, vírusszűrő SMTP gateway funkciót valósít meg.

3         Az Informatikai Központ számítógépes laborjainak, és az összes tanszéki hálózatnak a központi üzemeltetésére kidolgozott rendszer

3.1        Az egyetem levelezőrendszerét, a honlap adatbázisát és a laborok SaMBA alapú Windows NT tartományát integráló, weben keresztül menedzselhető rendszer

A Nyugat-Magyarországi Egyetem soproni egyetemi karainak Informatikai Központjában öt rendszergazda üzemelteti a hivatalos központi webszervert, a hivatalos levelezőszervert, és több központi szerepet játszó fájlszervert is.

Az egyetemi honlapon található telefonkönyv - amelyből a puszta telefonszámon kívül az egyetemi dolgozók e-mail címei és néhány egyéb adata is lekérdezhető - SQL adatbázison alapuló PHP szkriptekből áll. A hivatalos központi levelezőszerver UNIX jelszóadatbázisa is ugyanezen felhasználók adatait tartalmazza ugyanúgy, mint a levelezőszerveren a felhasználók saját tárterületét megosztó SaMBa programcsomag különböző titkosítású jelszavakat tartalmazó adatbázisa. Célszerűnek tűnt egy olyan rendszer kifejlesztése, amely egyesíti ezeket az adatbázisokat. Ezt az idők folyamán lassan változó és tökéletesedő rendszert a rendszergazdák írták meg Bash, PHP és Perl interpreterek számára.

A rendszer elsődleges adatbázisának szerepét az egyetemi honlap MySQL adatbázisa kapta. Ezt az adatbázist egy adminisztratív weboldalon keresztül tartjuk karban, amelyhez csak a rendszergazdák férnek hozzá, és PHP nyelven íródott. A PHP szkripteket kibővítettük úgy, hogy bármilyen módosítást végeznek a központi adatbázison, azt szövegfájlokba regisztrálják. Ezen szövegfájlok értelmezésére olyan shell- és Perl szkripteket írtunk, amelyek az elsődleges adatbázis változásainak megfelelően módosítják a UNIX és SaMBa adatbázisokat. Új felhasználó létrehozásakor beállítják a hozzáférés lejárati dátumát, a felhasználó személyes tárhelyének méretét és munkakörnyezetének biztonsági szempontból szükséges korlátozásait. Az e-mail cím domain részének megfelelően bekonfigurálják a felhasználó UNIX-os levelezőprogramját, véletlenszerűen generált induló jelszóval látják el, személyre szabott nyomtatott levélben tájékoztatják a hozzáférés használatba vételével kapcsolatos teendőkről, stb. Ugyanez a szkriptrendszer a felhasználók adatainak módosításakor, vagy felhasználók törlésekor is elvégzi a rendszerek között a szükséges szinkronizációt.

3.2        Hatékony telepítés Symantec Ghost programcsomaggal

A Nyugat-Magyarországi Egyetem három soproni egyetemi karán a hallgatói laborok munkaállomásait és a tanszéki számítógépeket egybevetve megközelítően ötszáz számítógép üzemel. Ezek jelentős részén az Informatikai Központ három rendszergazdája végzi el a telepítési és karbantartási munkákat. A felhasználók által szándékosan vagy véletlenül okozott hibákból, az - utóbbi időkben már csak elvétve előforduló - víruskárokból, a megbízhatatlan hardverek vagy rosszul tervezett szoftverek által előidézett adatvesztésekből, inkonzisztenciából adódóan esetenként szükségessé válik a számítógépek újratelepítése. Hogy ez minél hatékonyabban történhessen, olyan módon telepítjük a számítógépeket, hogy a felhasználóktól megvonjuk a programok telepítésének jogát. Ezen felül külön rendszer- és adatpartíciót hozunk létre, és ha lehetséges, a Dokumentumok mappát, az aktuális levelezőprogram tárolómappáját és más hasonló alapkönyvtárakat az adatpartícióra irányítunk át, így elérhetjük azt, hogy rendeltetésszerű használat esetén a rendszerpartíció gyakorlatilag nem változik. A számítógépek kezdeti telepítésekor az operációs rendszer, a szükséges programcsomagok, és minden lehetséges frissítés valamint a legújabb meghajtóprogramok telepítése után a Symantec Ghost programcsomaggal image fájlt készítünk a rendszerpartícióról, amelyet CD-re vagy DVD-re írunk. Mivel a rendszerpartíció a használat során gyakorlatilag változatlan marad, ha a rendszer újratelepítésére van szükség, ez zökkenőmentesen megoldható az elmentett image-ből boot-oló CD lemezek segítségével. Ezek a Ghost programcsomagon kívül a leggyakrabban használt hálózati kártyák meghajtóit is tartalmazzák, olyan esetekre felkészülve, amikor hálózaton keresztüli rendszervisszaállítást végzünk (pl. a laborok multicast jellegű újratelepítése esetén).

3.3        A Windows kliensek NTP szinkronizálása a Linux szerverekhez

Az intézményi hálózatra csatlakozó munkaállomások nagy részén, főként az Informatikai Központ által üzemeltetett gépeken Windows 2000 operációs rendszer fut. A Windows 2000 operációs rendszerrel megjelent Active Directory alapú tartományi rendszer egyik fontos eleme a Kerberos kompatíbilis authentikáció, aminek a működéséhez szükség van arra, hogy az egyazon tartományba tartozó számítógépek rendszerórái egy észszerű tűréshatáron belül egyszerre járjanak. Ez okból kifolyólag a Microsoft a Windows 2000 operációs rendszertől fogva nagyobb gondot fordít a hálózaton keresztüli rendszeridő szinkronizálásra. Az új Windows Idő (w32time) szolgáltatás a már említett xntp démonhoz hasonlóan képes a helyi rendszeridőnek hálózaton keresztül elérhető referenciaszerverekhez történő szinkronizálására és referenciaszerverként történő működésre is. A pontos idő átviteléhez az xntp rendszer által "beszélt" NTP protokoll egyszerűsített változatát, az SNTP-t vagy a Netbios protokoll szolgáltatásait használja. A Windows Idő rendszerről nagy vonalakban elmondható, hogy a tartomány munkaállomásai, a társszerverek, és a tartományvezérlők Netbios protokollal kérdezik le az időt egy olyan hierarchiában, amelynek csúcsán az elsődleges tartományvezérlő áll, amely alapértelmezésben egyszerűen megbízik a saját órájában, így igaz ugyan, hogy a tartományban minden óra egyszerre jár, de ezek nem biztos, hogy szinkronban vannak a pontos idővel. A tartomány pontos időhöz történő hozzáállításának bevett módja, hogy az elsődleges tartományvezérlő egy külső NTP szerverhez kapcsolódik.

Az Informatikai Központ létrehozott egy Windows tartományt Windows 2000-es számítógépekből. A tartomány elsődleges tartományvezérlője egy 2.2-es verziójú SaMBa szerver, amelytől a munkaállomásokon futó Windows Idő szolgáltatások ismeretlen okból nem kérdezik le Netbios protokollal az időt. Mivel a tartomány nem Active Directory alapú, így Kerberos authentikáció sincs, tehát nem létszükséglet a rendszeridők egymáshoz és a pontos időhöz történő szinkronizálása. Ennek ellenére mégis úgy döntöttünk, hogy a Windows munkaállomásokat is bekapcsoljuk a Linux szerverek NTP rendszerébe. Kezdetben az Automachron nevű (http://oneguycoding.com/automachron) ingyenes SNTP klienst használtuk, amely lényegesen jobban skálázható a beépített Windows Idő szolgáltatásnál, de attól eltérően nem szolgáltatásként fut, hanem az indítópultból indul. Ez a fajta megoldás több súlyos hátránnyal jár. Csak akkor van szigorúan szinkronban az idő, ha valaki bejelentkezett a számítógépre, ami szerverek esetében néha napokig nem történik meg. A felhasználókat fel kell ruházni a rendszeridő megváltoztatásának jogával, ami viszont a munkaállomások esetében ad lehetőséget visszaélésekre, nem is beszélve arról, hogy a hallgatók az óra kézi átállításán kívül leállíthatják, vagy átkonfigurálhatják magát az automachron programot is.

A Windows 2000 teljeskörű elterjedésének köszönhetően átállunk a beépített Windows Idő (w32time) szolgáltatás használatára. Igaz, hogy ez kevésbé skálázható, és kisebb pontosságú, mint az Automachron. A Linux szervereken futó xntp szerverekhez képest pedig még nagyobb lemaradásban van ezen a téren, de még messze az elviselhetőség határán belül van, és nagy előnye, hogy szolgáltatás mivoltából kifolyólag állandóan fut a közönséges felhasználók számára láthatatlan és befolyásolhatatlan módon. Mivel a SaMBa által vezérel tartományban a kézi konfigurációmódosítás nélkül alapértelmezett paraméterekkel futó Windows Idő szolgáltatások effektíve semmit sem csináltak, azt a megoldást választottuk, hogy minden munkaállomás esetében egyszerűen a tartományon kívüli xntp-t futtató NTP szervereket adjuk meg a pontos idő forrásaként. Ehhez a regisztrációs adatbázisnak a w32time szolgáltatás paramétereit tartalmazó részében kell néhány változót átírni, de a közvetlen szerkesztés helyett biztonságosabb és egyszerűbb a NET TIME parancssori utasítás használata.

3.4        A munkaállomások általános vírusvédelme VirusBuster rendszerrel

Mivel a soproni egyetemi karokon a hallgatói laborok számítógépein kívül szinte az összes tanszéki számítógépen is az Egyetemi Informatikai Központ három rendszergazdája végzi a telepítési és karbantartási munkálatokat, a vírusok által okozott károk helyreállítása egyre több felesleges többletfeladatot jelentett. 2000-ben kezdtünk olyan megoldást keresni, amely lehetőség szerint az egész Nyugat-Magyarországi Egyetem teljes informatikai rendszere számára vírusvédelmet biztosít. A munkaállomások egyenkénti vírusirtóval való felszerelésén kívül a fontosabb szerverfunkciókat is védelem alá szerettük volna helyezni. Miután több neves vírusirtó termékcsalád hazai forgalmazójával tárgyalásokat folytattunk, úgy találtuk, hogy a hazai VirusBuster Kft. által a számunkra kidolgozott üzleti ajánlat messze a legoptimálisabb megoldás. A velük kötött szerződés keretében minden elérhető munkaállomás- és szerveroldali védelmi rendszerre licenszjogot kaptunk ötezer számítógépre.

A levelzőrendszer vírusvédelmét korábban már említettük. A munkaállomások védelmét ellátó VirusBuster for Windows Workstations és VBShield for Microsoft Office programcsomagok nem csak a fájlokba ágyazott program- és makrovírusokat képes megtalálni és irtani, hanem az Office anti-virus API segítségével a fájlrendszer szinten meg sem jelenő adatállományokban megbúvókat is. A termékcsalád dinamikusan fejlődik, vírustalálati aránya igen magas, és a legutóbbi fejlesztéseknek köszönhetően már a működési teljesítménye és megbízhatósága is kiváló, ezen kívül rengeteg szolgáltatást nyújt felhasználóbarát felületén keresztül.

4         Dióhéjban az egyetemi honlap fejlesztéséről (http://www.nyme.hu)

4.1        Az egyetemi honlap adatbázisának a Neptun-rendszer adatbázisából történő táplálása

Az egyetemi honlap tervezésekor az alapkoncepció a lehető legtöbb (naprakész) információ egységes struktúrában való megjelenítése volt. A honlap készítéséhez egy MySQL alapú adatbázist építettük fel, mely a szervezeti egységektől, az egyetem tanulói, dolgozói adatain át az oktatással kapcsolatos információkat tartalmazza. Az adatok feltöltéséhez adminisztratív felületeket terveztünk, illetve elkezdtünk kidolgozni egy jogosultsági rendszert, mely az adatkarbantartás alapjául szolgál. A fejlesztés már folyt, amikor az intézmény megvásárolta és elkezdte alkalmazni a NEPTUN egységes tanulmányi és pénzügyi rendszert a tanulmányi ügyek adminisztrációjához. Mivel ezen rendszer minden tanulmányi ügyet naprakészen tartalmaz, a honlap további fejlesztését a NEPTUN működésével összekapcsolva végeztük. A tanulmányi rendszer adatai Oracle adatbázisban vannak, melyhez a fejlesztőktől hozzáférést nem kaptunk. Napi szinkronizációval gondoskodunk az egyetemi MySQL adatbázis frissítéséről. Szűréseket végzünk a NEPTUN rendszerben, majd a szükséges adatokat szövegfájlba emeljük ki, és egy Perl szkript segítségével beemeljük ezeket az egyetemi adatbázisba. Az adatbázis-szerkezetet időközben át kellett alakítanunk, hogy az új azonosítók és egyéb attribútumok is helyet kapjanak benne. Most dolgozunk olyan adminisztratív felületek kialakításán, melyek segítségével a NEPTUN rendszerben tárolt adatokon kívül, azokat kiegészítve egyéb tanulmányi ügyekkel kapcsolatos információkat is rögzíthetnek kari, illetve tanszéki szinten. Azt tervezzük, hogy a saját felületen keresztüli adatmódosításokat a fentihez hasonló módon a NEPTUN adatbázisával szinkronizáljuk. Az átalakított adatbázis-szerkezeten alapuló, a NEPTUN-nal naponta szinkronizált honlap tesztverziója már elérhető. Folyamatosan bővül a kari igényeknek megfelelően. Terveink szerint a 2003/04-es tanév elindulására, amikorra már a NEPTUN adatbázisa is teljes lesz, egy működő, nyilvános rendszerré válik.

4.2        Az Alkalmazott Művészeti Intézet hallgatói által tervezett arculat

A Nyugat-Magyarországi Egyetem honlapja másfél évvel ezelőtt hat teljesen különböző struktúrájú és színvonalú honlapból állt. A http://www.nyme.hu címen csupán a különböző kari honlapokra mutató linkek és néhány idejétmúlt általános információ volt található. Az egyes karok eltérő szerkezetű és információtartalmú oldalakat készítettek, melyek sok esetben nem voltak naprakészek. Idejét láttuk egy új, egységes honlap készítésének, melyen könnyű a navigáció, azonos formában juthat a látogató információhoz minden karról. A tervezés első lépéseként külföldi egyetemek honlapjait látogattuk meg. Azt tapasztaltuk, hogy egyszerű, letisztult megjelenéssel sokrétű információkat szolgáltatnak. Az új arculat kialakításához egyetemünk Alkalmazott Művészeti Intézetének három hallgatóját kértük fel. Az oldalakat igyekeztünk úgy tervezni, hogy a látogató könnyen tájékozódhasson, mindig legyen lehetősége bármely karral kapcsolatos információk megtekintésére. A munka végeredményeként elkészült az új kezdőoldal, az általános belső oldalak, a kari nyitó oldalak, a képzések, a telefonkönyv és szervezeti felépítés, térképek és néhány formanyomtatvány arculati terve. Ezzel együtt az egyes karok jellegüknek megfelelően egyedi színeket kaptak az arculatban. Az oldalakat úgy kódoltuk, hogy az ismertebb böngészőkben a legkisebb eltéréssel jelenjenek meg.

A Nyugat-Magyarországi Egyetem honlapjának kezdő oldala az új arculattal: