NEPTUN.NET ÜZEMELTETÉS

NEPTUN.NET ÜZEMELTETÉS Felhasználói dokumentáció verzió 3.10

Budapest, 2014.

NEPTUN Tanulmányi Rendszer Dokumentáció

NEPTUN ÜZEMELTETÉS

Változáskezelés Tisztelt Felhasználó! Jelen dokumentum olyan sok változást tartalmaz az utoljára kiadott v2.14-hez képest, hogy a listát kiürítettük, hiszen a dokumentum legtöbb fejezete változott tartalmilag kisebb-nagyobb mértékben. A változáskezelés vonatkozásában a v3.0 kiadást tekintjük a jövőbeni változások alapjának. Verzió 3.0 3.1 3.1 3.1 3.1 3.2 3.2 3.2 3.3 3.3 3.3 3.3 3.4 3.4 3.4 3.4 3.4 3.4 3.4 3.4 3.4 3.4 3.4 3.5 3.6 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.8 3.8 3.8 3.8 3.9 3.9 3.9 3.9 3.9 3.9

Dátum 2012.09.24. 2012.11.13. 2012.11.13. 2012.11.13. 2012.11.13. 2012.11.26. 2012.11.26. 2012.11.26. 2013.03.11. 2013.03.11. 2013.03.11. 2013.03.11. 2013.07.09. 2013.07.09. 2013.07.09. 2013.07.09. 2013.07.09. 2013.07.09. 2013.07.09. 2013.07.09. 2013.07.09. 2013.07.09. 2013.07.09. 2013.08.09. 2013.09.10. 2013.11.11. 2013.11.11. 2013.11.11. 2013.11.11. 2013.11.11. 2013.11.11. 2013.11.11. 2014.03.19. 2014.03.19. 2014.03.19. 2014.03.19. 2014.07.28. 2014.07.28. 2014.07.28. 2014.07.28. 2014.07.28. 2014.07.28.

Változás Pont * 2.1.1.4. 2.1.1.6.1. 2.2.7.2. 2.2.8.2. 1.4. 2.2.7.1. 2.3.7. 3.1.1.2. 3.1.2.4. 5.3.2. 5.4. 1.3. 2.2.1. 2.2.1.1. 2.3.4. 2.3.8. 2.6.*. 2.7.5. 2.8.5. 5.3. 5.4. 5.6. 2.3.8. 2.9. 1.3 1.4.2. 2.2.1 2.7.5. 2.8.2. 2.8.4. 5.6. 1.3. 2.2.1. 2.2.1.2. 2.3.3.1. 1.3. 2.2.1. 2.2.1.1.1. 2.2.1.1.2. 2.2.5. 2.2.8.3.2.

Kiadás: 2014.08.07.

Cím A teljes dokumentum változott Táblaterek kialakítása Oracle adatbázis-kezelő rendszeren Egyedi PROFILE alkalmazás A Neptun.NET Windows service futtató felhasználó beállítása Üzenetküldés beállításai és működése Kliens működése IBM MQ kliens telepítése Terheléselosztás Ütemezés Adatbázis mentése ARCHIVELOG módban, RMAN segítségével Manuális verzió kihelyezés Licenszállomány kihelyezésének és cseréjének folyamata Az alkalmazás szerver működése Előfeltételek Oracle kliens telepítés Web rendszer-adminisztrációs felület Kapcsolat a Diákhitel rendszerrel Neptun címtárszolgáltatás (minden alfejezet!) Elektronikus számlázáshoz szükséges beállítások FIR Tanúsítványok Verzió- és javítócsomag kihelyezése Licenszállomány kihelyezésének és cseréjének folyamata FIR XML szétbontás Kapcsolat a Diákhitel rendszerrel Kapcsolat a Diákhitel rendszerrel (új fejezetszám!) Az alkalmazás szerver működése FIR kliens oldali komponenseinek telepítése Előfeltételek Elektronikus számlázáshoz szükséges beállítások Tanúsítványok elektronikus számlázáshoz FIR Tanúsítványok (minden alfejezet!) FIR XML szétbontás, konténerek tömörítése Az alkalmazás szerver működése Előfeltételek Az Oracle DataProvider regisztrálása, újraregisztrálása GAC-ba .NET Framework regisztrálása-újraregisztrálása IIS alá Az alkalmazás szerver működése Előfeltételek Nem managelt DataAccess Managelt DataAccess AD autentikáció Application pool létrehozása

Verzió: 3.10

Oldal * 39 42 95 106 11 91 141 163 167 184 192 10 70 72 133 142 153 163 169 191 199 201 142 162 10 14 70 154 156 161 204 10 70 81 133 11 71 80 82 88 112

Oldalszám: 2 / 231

NEPTUN Tanulmányi Rendszer Dokumentáció 3.9 3.9 3.10 3.10 3.10

2014.07.28. 2014.07.28. 2014.08.07. 2014.08.07. 2014.08.07.

2.2.8.4.1. 4.2.1. 2.2.5. 2.6.4. 2.6.5.

Kiadás: 2014.08.07.

NEPTUN ÜZEMELTETÉS Szoftver követelmény Adatok áttöltése Oracle adatbázis-kezelő rendszeren AD autentikáció A címtárszolgáltatás működése A címtárszolgáltatás beállítása

Verzió: 3.10

Oldalszám: 3 / 231

115 191 88 148 152



Tartalomjegyzék 1. A Neptun.NET rendszer felépítése .................................................................... 9 1.1. Hálózati architektúra .......................................................................................... 9 1.2. Adatbázis jellemzők .......................................................................................... 10 1.3. Az alkalmazás szerver működése ....................................................................... 11 1.4. Kliens működése .............................................................................................. 12 1.4.1. Kliens indítás és frissítés ............................................................................. 13 1.4.2. FIR kliens oldali komponenseinek telepítése ................................................. 15 1.5. A webalkalmazás működése .............................................................................. 17 2. Telepítési információk .................................................................................... 19 2.1. Adatbázis telepítése.......................................................................................... 19 2.1.1. Oracle Database 11g R2 ............................................................................. 19 2.1.1.1. Az Oracle rendszer telepítése ................................................................ 20 2.1.1.2. Listener telepítés ................................................................................. 27 2.1.1.3. Adatbázispéldány létrehozása ............................................................... 30 2.1.1.4. Táblaterek kialakítása Oracle adatbázis-kezelő rendszeren ...................... 40 2.1.1.5. Adatfájlok kialakítása a táblaterekhez .................................................... 41 2.1.1.6. Sémák kialakítása ................................................................................ 42 2.1.1.6.1. Egyedi PROFILE alkalmazás ............................................................ 43 2.1.1.7. Adatbázis létrehozása template segítségével .......................................... 44 2.1.2. Microsoft SQL Server .................................................................................. 44 2.1.2.1. Login létrehozása a Neptun3R tanulmányi rendszer adatbázisához .......... 58 2.1.2.2. Adatbázis létrehozása a Neptun3R tanulmányi rendszer adatai számára .. 63 2.2. Alkalmazás szerver telepítése ............................................................................ 71 2.2.1. Előfeltételek ............................................................................................... 71 2.2.1.1. Oracle kliens telepítése: ....................................................................... 73 2.2.1.1.1. Nem managelt DataAccess ............................................................. 80 2.2.1.1.2. Managelt DataAccess ..................................................................... 82 2.2.1.2. Az Oracle DataProvider regisztrálása, újraregisztrálása GAC-ba ............... 83 2.2.2. Könyvtárszerkezet ...................................................................................... 84 2.2.3. Nevesített Windows Service telepítése ......................................................... 84 2.2.4. Konfigurációs állományok beállítása ............................................................ 86 2.2.5. AD autentikáció.......................................................................................... 88 2.2.6. Alkalmazás szerver indítása ........................................................................ 91 2.2.7. FIR beüzemelése ....................................................................................... 93 2.2.7.1. IBM MQ kliens telepítése ...................................................................... 94 2.2.7.2. A Neptun.NET Windows service futtató felhasználó beállítása ................. 97 2.2.7.3. A FIR kulcsok beállítása ........................................................................ 99 2.2.8. Alkalmazás szerver működése ....................................................................104 2.2.8.1. Alkalmazás szerver parancsai ...............................................................106 2.2.8.2. Üzenetküldés beállításai és működése ..................................................108 2.2.8.3. LMS telepítése ....................................................................................111 2.2.8.3.1. Fájlok másolása ............................................................................111 2.2.8.3.2. Application pool létrehozása ..........................................................112 2.2.8.3.3. Virtuális mappák létrehozása .........................................................112 2.2.8.3.4. Web.config beállítások ..................................................................112

Kiadás: 2014.08.07.

Verzió: 3.10

Oldalszám: 4 / 231



2.2.8.4. LDAP szervizek telepítési dokumentációja .............................................115 2.2.8.4.1. Szoftver követelmény ....................................................................115 2.2.8.4.2. Beállítások IIS 7.x alatt .................................................................115 2.2.8.4.3. Web.config beállítások ..................................................................115 2.2.8.4.4. Neptun DLL igények ......................................................................116 2.2.8.4.5. Szervizek aktualizálása ..................................................................116 2.2.8.4.6. A szervizek szolgáltatásairól ...........................................................116 2.2.8.5. Filetárolók beállításai ...........................................................................116 2.2.8.6. Neptun MeetStreet (közösségi tér) beállítása ........................................119 2.3. WEB alkalmazás ..............................................................................................120 2.3.1. Könyvtár szerkezet ....................................................................................120 2.3.2. Konfigurációs állományok beállítása ...........................................................121 2.3.3. Az IIS webkiszolgáló telepítése ..................................................................123 2.3.3.1. .NET Framework regisztrálása-újraregisztrálása IIS alá ..........................135 2.3.4. Web rendszer-adminisztrációs felület ..........................................................136 2.3.5. AD Autentikáció ........................................................................................141 2.3.6. Web szerver indítási feltételek....................................................................141 2.3.7. Terheléselosztás .......................................................................................145 2.4. Kliens telepítése ..............................................................................................145 2.5. Hálózati beállítások..........................................................................................146 2.6. Neptun címtárszolgáltatás ................................................................................147 2.6.1. A címtárszolgáltatás leírása ........................................................................147 2.6.2. A címtárszolgáltatás funkciói ......................................................................147 2.6.3. A címtárszolgáltatás paraméterei................................................................148 2.6.4. A címtárszolgáltatás működése ..................................................................148 2.6.5. A címtárszolgáltatás beállítása....................................................................152 2.7. Elektronikus aláírás és számlázás feltételei ........................................................153 2.7.1. Médiumok.................................................................................................154 2.7.2. Típusok ....................................................................................................155 2.7.3. Telepítés ..................................................................................................156 2.7.4. Kompromittálódás .....................................................................................157 2.7.5. Elektronikus számlázáshoz szükséges beállítások ........................................157 2.8. Tanúsítványkezelés Neptun.NET rendszerekben ................................................158 2.8.1. Tanúsítvány Neptun.NET kiszolgáló futtatásához .........................................158 2.8.2. Tanúsítványok elektronikus számlázáshoz ...................................................159 2.8.3. Főtanúsítványok, hitelesítés-szolgáltatók ....................................................163 2.8.4. FIR tanúsítványok .....................................................................................164 2.8.4.1. Aláíró tanúsítvány – kliens oldali aláírás esetén .....................................164 2.8.4.2. Aláíró tanúsítvány – szerver oldali aláírás esetén ...................................165 2.8.4.3. FIR kommunikációs csatornával kapcsolatos állományok .......................166 2.8.4.4. FIR aláírás metódusának kiválasztása ...................................................166 2.9. Kapcsolat a Diákhitel-rendszerrel ......................................................................166 3. Rendelkezésre állás ...................................................................................... 177 3.1. Adatbázis üzemeltetése ...................................................................................177 3.1.1. Mentés és helyreállítás ..............................................................................177 3.1.1.1. Beállítások ..........................................................................................178 3.1.1.2. Ütemezés ...........................................................................................178 3.1.1.3. Tesztelés ............................................................................................179 3.1.1.4. Megfigyelés ........................................................................................179

Kiadás: 2014.08.07.

Verzió: 3.10

Oldalszám: 5 / 231



3.1.1.5. Visszaállítás ........................................................................................180 3.1.1.6. Helyreállítás ........................................................................................180 3.1.2. Adatbázis mentése és helyreállítása Oracle adatbázison ...............................180 3.1.2.1. Adatbázis mentése NOARCHIVELOG módban ........................................181 3.1.2.2. Adatbázis visszaállítása NOARCHIVELOG módban .................................181 3.1.2.3. Adatbázis mentése ARCHIVELOG módban ...........................................182 3.1.2.4. Adatbázis mentése ARCHIVELOG módban, RMAN segítségével ..............182 3.1.2.5. Adatbázis helyreállítása ARCHIVELOG módban ......................................185 3.1.2.6. A teljes és a részleges helyreállítás összehasonlítása .............................185 3.1.2.7. Lemezhiba és helyreállítás ARCHIVELOG módban .................................186 3.2. Katasztrófaterv................................................................................................189 3.2.1. Katasztrófaterv szükségessége ...................................................................189 3.2.2. Megelőző intézkedések ..............................................................................189 3.2.3. Katasztrófa esetén értesítendő személyek ...................................................190 3.2.4. Keletkezett kár felmérése ..........................................................................190 3.2.5. Helyreállítás ..............................................................................................190 4. Teszt rendszerek ........................................................................................... 191 4.1. Tesztrendszer fogalma.....................................................................................191 4.2. Tesztrendszer naprakészen-tartása, éles adatok időszakos áttöltése ...................191 4.2.1. Adatok áttöltése Oracle adatbázis-kezelő rendszeren ...................................191 4.2.2. Adatok áttöltése MSSQL adatbázis-kezelő rendszeren ..................................194 5. Verzió kihelyezés .......................................................................................... 196 5.1. A verzió kihelyezés esemény előzménye ...........................................................196 5.2. Igénylés, végrehajtás, értesítés ........................................................................196 5.3. Verzió- és javítócsomag kihelyezése .................................................................197 5.4. Licenszállomány kihelyezésének és cseréjének folyamata...................................205 5.5. LOB típusú oszlopok konverziója ......................................................................206 5.6. FIR XML szétbontás, konténerek tömörítése ......................................................207 6. Adatgyűjtés, statisztika, riportok ................................................................. 210 6.1. Rendszer működéséről.....................................................................................210 6.2. Adatbázis működése ........................................................................................210 6.3. Adatgyűjtés a Neptun működéséről ..................................................................210 6.3.1.1. Tárgyfelvételek száma .........................................................................210 6.3.1.2. Vizsgajelentkezések száma ..................................................................211 7. Biztonságtechnikai megoldások ................................................................... 213 7.1. Adat- és információvédelem .............................................................................213 7.2. Komplex informatikai biztonság ........................................................................213 7.2.1. Az adatvédelem célja.................................................................................213 7.2.2. Teljes körű védelem ..................................................................................213 7.2.3. Megoldások körei ......................................................................................214 7.3. Általános adatvédelmi megoldások ...................................................................214 7.3.1. Fizikai védelem .........................................................................................214 7.3.2. Hardveres védelem ...................................................................................215 7.3.3. Szoftveres védelem ...................................................................................215 7.3.3.1. Megfelelő lépések és kockázatbecslés ...................................................215 7.4. Neptun.NET rendszer biztonsági megoldások ....................................................216

Kiadás: 2014.08.07.

Verzió: 3.10

Oldalszám: 6 / 231



7.4.1. Adattitkosítás az alkalmazás és adatbázis szerverek között ..........................216 7.4.2. Alkalmazásszerver és kliens közötti biztonságtechnikai lehetőségek ..............216 7.4.3. Neptun.NET web kliensek adatforgalmának védelme ...................................217 7.4.3.1. Webreugrás webservice biztonsági lehetőségek ....................................217 7.4.4. Jogosultság és szerepkör ...........................................................................218 7.4.5. Használjon erős jelszavakat .......................................................................219 7.4.6. Jelszavak tárolása .....................................................................................219 7.4.7. Jelszó szabályok ........................................................................................220 7.5. Neptun.NET rendszer beléptetési metódusai .....................................................222 7.5.1. Hagyományos jelszavas autentikáció ..........................................................222 7.5.2. Központi autentikáció használatával ...........................................................222 7.6. Konfigurációs állományok védelme ...................................................................223 7.7. Reaktív és proaktív tevékenységek ...................................................................223 7.8. Adatbázisszerver védelme ................................................................................223 7.9. Felhasználók képzése ......................................................................................224 8. Együttműködés a Poszeidon rendszerrel ..................................................... 225 8.1. Együttműködés fogalma ..................................................................................225 8.2. Adatbázis kialakítása .......................................................................................225 8.2.1. Együttműködési sémanév beállítása ...........................................................226 8.3. Verzió kompatibilitás .......................................................................................226 8.4. Tesztrendszer frissítése ...................................................................................227 9. Szószedet ...................................................................................................... 228

Kiadás: 2014.08.07.

Verzió: 3.10

Oldalszám: 7 / 231



Információ a rendszerüzemeltetési dokumentációról A dokumentáció készítői Jelen leírást a Neptun.NET - Egységes Tanulmányi Rendszert készítő SDA Informatika Zrt. munkatársai állították össze azon intézmények számára, akik az üzemeltetést önálló módon végzik. A leírás általánosan alkalmazható minden Neptun.NET - Egységes Tanulmányi Rendszert használó intézmény számára, amely jelen dokumentáció második fejezetében leírt telepítési információknak megfelelően alakította ki a rendszert.

Kiadás: 2014.08.07.

Verzió: 3.10

Oldalszám: 8 / 231



1. A Neptun.NET rendszer felépítése 1.1. Hálózati architektúra A rendszer, felépítését illetően egy adatbázis-szerverből, legalább egy alkalmazás-szerverből és web-szerverből áll. Ez a három réteg első két rétege. Első rétegnek tekintjük magát az adatbázist. A második, azaz középréteg az alkalmazás, illetve a web szerver. Ezekhez kapcsolódnak a kliensek, mint harmadik réteg. Adatbázis szerverből csak egy lehet (a szerverparkot is egy adatbázis szervernek tekintjük), míg a középréteg szerverek száma korlátlan lehet. Technikailag ezen szerepek akár egyetlen kiszolgáló gépre is kerülhetnek, de ez biztonsági szempontból nem javasolt, illetve erőforrás tekintetében sem javasolt egy bizonyos felhasználószám felett a közös kiszolgáló szerver használata. A kliens-alkalmazásoknál meg kell különböztetni a natív klienst, illetve a webes (ez lehet hallgatói és oktatói) klienst. A natív klienst csak dedikált felhasználók futtathatják lehetőleg csak a belső hálózaton. Biztonsági okokból nem javasoljuk a natív kliens távolról (intézményi hálózaton kívülről) történő futtatását. Mivel ez egy dedikált porton kapcsolódik az alkalmazás szerverhez, aminek a kinyitása biztonsági kockázat a hálózat, és az adatvédelem tekintetében.

Kiadás: 2014.08.07.

Verzió: 3.10

Oldalszám: 9 / 231



Amennyiben az intézmény felvállalja ezt a kockázatot, javasoljuk a VPN csatorna használatát ezzel minimalizálható a kockázat. A webes kliens természetesen bárhonnan használható, de itt is javasoljuk a csatorna titkosítását. A rétegek közti kapcsolatok és kommunikációs csatornák jól definiáltak és szabadon változtathatóak.

1.2. Adatbázis jellemzők A Neptun.NET egységes tanulmányi rendszer külső gyártó által készített adatbázis-kezelő szoftver segítségével tárolja a rendszerben keletkezett információkat. A középréteg alkalmazások keretrendszere általános SQL szabványra épül, így lehetőség van különböző gyártók termékét használni. Jelenleg két adatbázis-kezelő különböző verzióit támogatja a Neptun.NET egységes tanulmányi rendszer. Ezek név szerint az Oracle – Oracle Database, illetve a Microsoft – SQL Server termékcsaládjai. Támogatott adatbázis-kezelők pontos verziószámai:  Oracle Database 11g Release 2 Patchset 3 (11.2.0.3) Standard, Standard One vagy Enterprise Edition  Microsoft SQL Server 2008 R2 Service Pack 2  Microsoft SQL Server 2012

Kiadás: 2014.08.07.

Verzió: 3.10

Oldalszám: 10 / 231



Az adatbázis kezelő megválasztásánál fontos szempont a hallgatói létszám, illetve a kiemelt időszakokban jelentkező rendszerhasználat során fellépő adatbázis terhelés. Az adatbázis-kezelő rendszer beszerzése, telepítése, konfigurálása, hangolása és üzemeltetése minden esetben az intézmény/szervezet feladata, így jelen dokumentáció csak ajánlást ad a kiépítendő rendszerhez, ennek betartása nem kötelező, de az ettől eltérő telepítés a Neptun.NET egységes tanulmányi rendszer rendellenes működését okozhatja! A Neptun.NET egységes tanulmányi rendszerhez legtöbb esetben az Oracle által gyártott adatbázis-kezelő rendszert ajánljuk az azonos szerveren elérhető nagyobb teljesítmény érdekében. Amennyiben lehetőség van rá, az adatbázis-kezelőt minden esetben külön szerveren kell elhelyezni. A szerver operációs rendszere a választott adatbázis-kezelő szoftvernek megfelelő legyen, melyeket a gyártó megjelölt termékéhez. Az adatbázis-kezelő rendszer telepítéséhez 64 bites környezet kiépítését javasoljuk. Támogatott operációs rendszerek: 

Windows Server 2008 R2 Datacenter vagy Enterprise



Linux (Oracle Unbreakable Linux)

Az operációs rendszer megválasztása minden esetben a választott adatbázis-kezelő rendszerhez igazodjon, annak gyártói elvárásaitól semmilyen esetben se térjünk el. Az operációs rendszer beszerzése, telepítése, konfigurálása, hangolása és üzemeltetése minden esetben az intézmény/szervezet feladata, így jelen dokumentáció csak ajánlást ad a kiépítendő rendszerhez, ennek betartása nem kötelező, de az ettől eltérő telepítés a Neptun.NET egységes tanulmányi rendszer rendellenes működését okozhatja!

1.3. Az alkalmazás szerver működése Az alkalmazás szerver működésének alapfeltétele a támogatott operációs rendszeren való futtatás, illetve a szükséges keretrendszer és kiszolgáló alkalmazások megléte. Támogatott operációs rendszerek:  Microsoft Windows 2008 Server R2 Kiadás: 2014.08.07.

Verzió: 3.10




 Microsoft Windows 2008 Server Service Pack 2 Szükséges keretrendszer verziók:  Microsoft .NET Framework 4.5 (2014 nyári verziótól kezdődően) Szükséges kiszolgáló alkalmazások:  FIR rendszer használata esetén IBM MQ kliens ftp://fir:[email protected]/SzerverInstall/IBMMQ7.exe  Szolgáltatói tanúsítványok telepítője ftp://fir:[email protected]/SzerverInstall/szolgaltatoi_tanusitvanyok_telepitese.exe  FIR rendszer használata esetén a SDA.FIR.Configurator alkalmazás ftp://fir:[email protected]/SzerverInstall/SDA.FIR.Configurator.exe Kapcsolathoz szükséges komponensek:  Oracle adatbázis-kezelő szoftver esetén az adatbázissal megegyező verziójú kliens komponens megfelelő beállításokkal. Lásd: Alkalmazás szerver telepítése (2.2)  MSSQL adatbázis kezelő szoftver esetén az adatbázissal megegyező verziójú natív kliens komponens. Lásd: Alkalmazás szerver telepítése (2.2) Valamint értelemszerűen a Neptun3R rendszer szerveralkalmazása megfelelően felparaméterezve. Lásd: 2. fejezet - Telepítési információk

1.4. Kliens működése A Neptun3R kliens alkalmazása a háromrétegű alkalmazás harmadik rétege. A kliens program önállóan működő alkalmazás, mindössze egy TCP/IP kapcsolatra van szüksége az alkalmazás szerverrel és a frissítéshez megfelelő jogosultságra az adott gépen. Lásd: Kliens telepítése (2.4). Semmilyen keretrendszert vagy kiszolgáló alkalmazást nem igényel, amennyiben támogatott operációs rendszeren (Windows XP, Windows Vista, ill. Windows7) történik a futtatás. Nagyon fontos megjegyezni, hogy adott gépen adott könyvtárból csak egy felhasználó futtathatja a kliens programot és csak egy példányban. Ennek az az oka, hogy az alkalmazás minden induláskor összehasonlítja a verzióját a szerveren található kliens fájlokkal és szükség esetén frissíteni próbál. Ilyenkor másolás és átnevezés történik a frissítendő fájlokon, amit nem lehet elvégezni, ha egy másik felhasználó vagy egy másik példány fogja az aktuális fájlt. Ezért nagyon fontos, hogy a Kiadás: 2014.08.07.

Verzió: 3.10




kliens alkalmazás állománya a felhasználónál legyen lokálisan. A hálózati meghajtóról történő több felhasználós futtatás nem támogatott.

1.4.1. Kliens indítás és frissítés A kliens frissítés és működés alapfeltétele az alkalmazás szerveren meghatározott kommunikációs port (2-2) használata TCP/IP alapú http protokollal. Minden indítás során lezajlik a kliens verziójának ellenőrzése, ez a kommunikáció meglétének az ellenőrzése is egyben.

1. Neptun_reloaded.exe indítása: a program megkeresi és értelmezi a mellette elhelyezett konfigurációs fájlokat. Abban az esetben, ha ez első indítás, akkor a servers.cfg fájlt fogja megtalálni maga mellett mivel a kezdőcsomag csak ezt a két fájlt tartalmazza (Neptun_reloaded.exe és servers.cfg). Ha már volt indítva a kliens az adott könyvtárból, akkor létrejött egy client.cfg file is, amely tartalmazza a legutoljára használt szerver nevét, címét és kommunikációs port-ját. Sikeres belépést követően ugyanebbe a fájlba tárolódik le a használt felhasználó neve és az indításnál használt, a kliens működését befolyásoló kapcsolók is. Ha van megfelelő client.cfg file, de nincs servers.cfg file akkor is indítható a kliens, de ebben az esetben csak ahhoz az egyetlen szerverhez tudunk kapcsolódni, amit utoljára használtunk. Míg servers.cfg megléte esetén bármely az intézmény által használt és a servers.cfg-ben felsorolt Neptun3R szerver neve betöltésre kerül a kliens login felületének szerverválasztó kontroljába.

2. Kliens verziójának ellenőrzése: sikeres kapcsolódás esetén, a szerveren elhelyezett kliens fájlokkal összehasonlítás történik a verzió azonosság érdekében. Nem minden esetben

Kiadás: 2014.08.07.

Verzió: 3.10




történik frissítés. Minden kliens file rendelkezik egy CRC azonosítóval, amely meghatározza, hogy melyik verziójú szerverhez tartozik. Első induláskor értelemszerűen csak a Neptun_reloaded.exe és a servers.cfg fájl lesz az indító könyvtárban, tehát ezekre a fájlokra lefut az ellenőrzés, a többi file pedig automatikusan letöltésre kerül. Ha már volt indítva a kliens és az indító könyvtár fel van töltve, akkor minden fájlra lefut az ellenőrzés. Amennyiben nincs verzió eltérés, fájl letöltés nem történik, hanem azonnal indul a kliens. Ha bármely file hiányzik vagy elavult annak (és csak annak) a letöltése megtörténik, majd indul a kliens. Frissítés esetén az alkalmazás természetesen ezt kiírja. Amennyiben letöltés is történik azt egy folyamatjelzőn nyomon tudjuk követni.

3. Adatforgalom indítása: ha sikeres volt a frissítés és él a kapcsolat a szerverrel a login felületen megjelennek a rendelkezésre álló szerepkörök. A szerepkör és a program nyelvének kiválasztása után indítható a beléptetés folyamata. Ekkor már adatforgalom is van, mivel a belépő felhasználó jogosultságának megfelelő adatok feltöltésre kerülnek.

A kliens egyszerűsége miatt az ellenőrzés is egyszerű. -

amennyiben első indításnál nem történik meg a kezdőcsomag frissítése és nem töltődnek le a kliens fájlok a program „Hálózati kommunikációs hiba” üzenetet ad, ez azt jelenti, hogy a kliens gépnek nincs kapcsolata az alkalmazás szerverrel vagy sikertelen a frissítés. Ezt okozhatja a kliens gépen lévő munkakönyvtár hibás jogosultság beállítása vagy a kliens gép és az alkalmazás szerver közti hálózati kommunikációs hiba, engedélyezett a proxy

Kiadás: 2014.08.07.

Verzió: 3.10




használata, de csak abban az esetben, ha az nem befolyásolja, ill. módosítja az adatforgalmat.

1.4.2. FIR kliens oldali komponenseinek telepítése Amennyiben a FIR konténereket kliens-oldali elektronikus aláírással szeretnék hitelesíteni, az alábbi fejezetet feltétlenül olvassa el, amennyiben szerver-oldali aláírást használnak a kliensoldali telepítésekre nem lesz szükségük. A minősített (kártyás aláíró) tanúsítványokból, illetve kártyaolvasó eszközökből számtalan féle szerezhető be kereskedelmi forgalomban, így általánosan érvényes leírást nem tudunk adni a telepítésükhöz. A tanúsítványokhoz, illetve az olvasó-eszközökhöz, a kibocsátóik tudnak pontos leírást, instrukciót biztosítani. Ezen általános leírás Windows XP operációs rendszeren, HP KUS0133 billentyűzetbe épített kártyaolvasót használva, adminisztrátor jogú felhasználóval történő telepítést mutatja be. Kliens oldali előfeltételek .NET Framework 1.1 telepítése Mindenképp ügyelni kell arra, hogy az operációs rendszer nyelvének megfelelő telepítőkészletet szerezzünk be. A telepítő indításakor a varázsló első lépésben megerősítést kér a telepítés indításához. Továbbiakban fontos lépés nincs a telepítés során csak a licence elfogadása és a telepítés lépései láthatóak a varázslóban. .NET Framework 4.0 telepítése A NeptunDotNetFirSigner alkalmazás újabb verziója már .Net Framework 4.0 keretrendszerre épül, így ezt is fel kell telepíteni az aláíró kliensgépre. A kártyaolvasó eszköz telepítése Ezután csatlakoztassuk a kártyaolvasót. Ezen telepítési leírás elkészítésénél a HP KUS0133-as billentyűzetbe integrált chipkártya olvasót használtam. Csatlakoztatás után az operációs rendszer felismeri az új eszközt és felkínálja az internetről történő driver telepítését. Éljünk a lehetőséggel és engedélyezzük az automatikus telepítést.

Kiadás: 2014.08.07.

Verzió: 3.10




Sikeres telepítés után az eszközkezelőben is megjelenek az új eszközök. Ettől függetlenül fel kell telepíteni a driver frissítését. Indítsuk el a „sp45492.exe” file-t. A telepítés teljesen automatikus. annyira, hogy az újraindításhoz sem kér beleegyezést. Miután újraindult a gép és beléptünk a billentyűzet és a kártyaolvasó megfelelően működik.

A kártyaolvasó szoftver telepítése Ez után lehet telepíteni az Axalto/Gemalto/stb klienst. Nagyon fontos a sorrend. Ameddig nem hibátlan a kártyaolvasó driver, nem lesz megfelelő a kliens telepítése sem. Tapasztalat, hogy rossz sorrendű telepítés esetén akkor sem működik az aláírás, ha egyébként minden komponens jól van feltelepítve. Az egyes kártyaolvasók különböző programok telepítését (Axalto, Gemalto, stb..) igénylik. Ezen programok telepítéséhez a kártya (és tanúsítvány) kibocsátójától kérhetnek telepítőt, és támogatást. Szolgáltatói tanúsítványok Utána az összes tanúsítványt és a root telepítő exe-t kell futtatni. Fontos hogy minden telepítést, a tanúsítványok telepítését leginkább azzal a felhasználóval belépve kell elvégezni, aki az aláírást fogja csinálni. Ellenkező esetben nem lesznek elérhetőek a komponensek és a tanúsítványok. Aláíró interfész alkalmazás A Neptun kliens és az kártyaolvasó alkalmazás (Axalto, Gemalto, stb.) közti interface a „NeptunDotNetFirSigner.msi”. Ezt az alkalmazást az SDA Informatika Zrt. fejlesztette. Nincs is

Kiadás: 2014.08.07.

Verzió: 3.10




vele gond, csak ha nincs feltelepítve, akkor az aláírásnál a Neptun kliens dobja a hibát, hogy nem találja az alkalmazást. A telepítőcsomag .NET Framework 1.1-es keretrendszerre épülő alkalmazást tartalmaz. Alapértelmezetten a „C:\Program files\SDA\NeptunDotNetFirSigner” könyvtárba települ. Ehhez még le kell tölteni egy frissítőcsomagot („FIRSigner_Net.zip”), amely már a .Net Framework 4.4 keretrendszerre épül. A zip file tartalmát ki kell csomagolni, és a tartalmával felülírni a „NeptunDotNetFirSigner” könyvtárban található azonos nevű állományokat. Ezek után ajánlott egy újraindítás és lehet tesztelni az aláírást!

1.5. A webalkalmazás működése A Neptun3R rendszer harmadik, ún. kliens oldali rétege nem csak natív, hanem webes kliens is lehet. Ebben az esetben a felhasználó egy web böngésző segítségével érheti el a web szerveren keresztül az adatokat. Itt is fel kell hívnom a figyelmet a támogatott böngészőprogramok használatára. Ezen alkalmazások neve megtalálható bejelentkező ablak legalsó sorában valamint a program bejelentkezés után ellenőrzést is végez. Amennyiben nem a támogatott böngészők egyikét használjuk figyelmeztető üzenet jelenik meg a felületen. Fejlesztés során az elkészített funkciókat csak ezekre az alkalmazásokra teszteljük és az ezeken jelentkező problémákat kezeljük bejelentés esetén. Minden más böngésző használata saját felelősségre történhet csak. A webalkalmazás csak SSL-titkosított kapcsolaton működhet, erről a webszerver telepítése során a 2.3.3. fejezetben még bővebben esik szó! Webes alkalmazásoknál meg kell különböztetni az oktatói és a hallgatói felületet. Az oktatói felületet csak az adatbázisban tárolt oktatók használhatják. Hallgatói Neptun kóddal és jelszóval nem engedélyezett a belépés. A hallgatói felület ugyancsak az adatbázisban tárolt hallgatók számára elérhető. Oktatók, illetve TO-s login direktbe nem engedélyezett. Ilyen belépés csak a natív kliens „webre ugrás” útján lehetséges melyhez a TO-s a saját Neptun kódját és jelszavát használja. Kapcsolat és bejelentkezés: A szerverrel való kapcsolatteremtés kétféle módon történhet. 1. Az intézmény hirdetmény útján közzéteszi az alkalmazás web címét, melyet a felhasználók kézzel visznek be a böngészőbe.

Kiadás: 2014.08.07.

Verzió: 3.10




2. Az intézmény a saját honlapján közvetlen linket biztosít a felhasználók számára a belépéshez. Ez a módszer nem csak azért ajánlott, mert kényelmesebb, de azért is, mert így az intézményi honlap és a Neptun szerver(ek) közé terheléselosztó iktatható be. A terheléselosztásról részletesebben a 2.3.5 részben. A kapcsolódáshoz nincs más követelmény, mint a web böngészőprogram megfelelő működése. Teljes topológia: A Neptun3R rendszer teljes topológiájának sematikus felépítése az alábbi képen látható.

Kiadás: 2014.08.07.

Verzió: 3.10




2. Telepítési információk 2.1. Adatbázis telepítése A Neptun.NET tanulmányi rendszer több operációs rendszeren több adatbázis-kezelő szoftvert támogat, így azok teljes mátrixának igénye nélkül a leggyakrabban használt operációs rendszer és adatbázis-kezelő telepítésének lépéseit mutatjuk be. A dokumentációtól eltérő operációs rendszeren történő telepítéshez minden esetben használjuk a gyártó által közzétett telepítési információkat, figyelembe véve a jelen dokumentációban megadott speciális paramétereket. A mindenkor beszerezhető telepítőkészletek eltérőek lehetnek a jelen dokumentáció készítése során használttól, ezért az egyes képernyőnézetekben eltérések mutatkozhatnak. A telepítés során hangsúlyt kell fektetni az adatbázis szerverhez kapcsolódó lemezek tömbjeinek kialakítására. Az adatbázis-kezelő rendszer számára három RAID 10-be szervezett tömb, illetve az operációs rendszer számára egy RAID 5 tömb kialakítása szükséges. A kialakított tömbök felhasználására a táblaterek illetve adatfájlok kialakításánál fogunk kitérni.

2.1.1. Oracle Database 11g R2 A telepítés megkezdése előtt ellenőrizzük a következő beállításokat. A területi és nyelvi beállításoknál a magyar nyelv legyen beállítva. Start\Settings\Control Panel\Regional and Language Options

Kiadás: 2014.08.07.

Verzió: 3.10




Jelentkezzen be egy olyan felhasználóval, akinek lesz joga telepítéseket végrehajtani, könyvtárakat létrehozni, rendszerállományokat szerkeszteni. Windows alatt mindenképp Adminisztrátor jogú felhasználóval jelentkezzen be és indítsa el a telepítőcsomag gyökérkönyvtárában található „setup.exe” programot!

2.1.1.1. Az Oracle rendszer telepítése Legelőször néhány ellenőrzést hajt végre a telepítő (pl.: támogatott szoftverkörnyezet, szabad hely), ha sikeresen lezajlott a művelet, az alább látható telepítőképernyő fogadja. Ha nem volt sikeres, értesíti Önt, hogy mi miatt nem folytatódhat a telepítés.

A telepítőprogram a számítógépen alkalmazott területi beállítások alapján választja kis a telepítés nyelvét. Ha nem az Ön által preferált nyelven indul el, ellenőrizze az operációs rendszer területi beállításait! „Step 1” oldalon lehetőséget ad egy email cím megadására. Erre a címre küld az Oracle rendszer kritikus biztonsági résekről szóló értesítéseket. Ajánlott kitölteni, de nem kötelező paraméter. Amennyiben rendelkezik azonosítóval a „My Oracle Support” oldalhoz, az azonosítóját itt megadhatja, azt is, így az Oracle értesítheti frissítésekről, és javítócsomagokról. Ehhez az Oracle licenszen feltüntetett licensz-azonosítót az Oracle terméktámogatási weboldalán az Ön accountjához hozzá kell rendelni. Az értesítések természetesen a support érvényessége alatt jönnek. A „Következő” gomb megnyomásával léphet tovább.

Kiadás: 2014.08.07.

Verzió: 3.10




Amennyiben nem adott meg email címet, egy figyelmeztetést dob fel a telepítő, de a „Yes” gombra kattintva folytathatja a telepítést.

A „Step 2” oldalon kiválaszthatja, milyen telepítést szeretne:  „Create and configure a database”: adatbázis-kezelő telepítése és beállítása,  „Install database software only”: csak adatbázis-kezelő telepítése,  „Upgrade an existing database”: adatbázis-kezelő frissítése. Javasoljuk, hogy csak az adatbázis-kezelőt telepítse, a konfiguráláshoz egy részletesebb beállítási lehetőségeket biztosító alkalmazást fogunk bemutatni. Válassza az „Install database software only”t, majd kattintson a Következő” –re!

Kiadás: 2014.08.07.

Verzió: 3.10




A következő lépésben ki kell választania, hogy egy egyszerű adatbázis-példányt szeretne felépíteni, vagy Oracle RAC-t („Real Application Cluster”). Az Oracle RAC több adatbázis-kiszolgálóból álló adatbázis-szerver fürt, de egy klaszter megtervezéséhez, beállításához, konfigurálásához mindenképpen Oracle szakértő bevonását javasoljuk! Jelen dokumentációban az egyszerű Oracle példány telepítését fogjuk bemutatni, válassza a képernyőn a „Single instance database installation”-t, majd a „Következő” gomb megnyomásával lépjen tovább!

Kiadás: 2014.08.07.

Verzió: 3.10




A rendszertelepítés első paramétere a támogatott nyelv kiválasztása. Az angol („English”) nyelv kötelezően a kiválasztott nyelvek közé kerül, illetve, ha az operációs rendszerének területi beállításai az angoltól eltérnek, – pl. magyar – a rendszer automatikusan azt a nyelvet is kiválasztja. Ha magyar beállításokkal szeretné telepíteni a rendszert, és nem ajánlotta fel automatikusan, ellenőrizze le az operációs rendszer területi beállításait! Ha további nyelvek támogatását is szeretné telepíteni, az „Available languages” („Elérhető nyelvek”) oszlop elemei közül, a nyelvet/nyelveket kijelölve a középen található nyilakkal helyezheti át a „Selected languages” („Kiválasztott nyelvek”) oszlopba. A nyelv(ek) kiválasztása után kattintson a „Következő” gombra!

A következő lépés a példány licenszelésének kiválasztása. Telepítés után az itt kiválasztott példány típusa nem módosítható! Keresse elő az Oracle licensz-szerződését, és a szerződésen található Oracle kiadásnak megfelelően válassza ki a telepítendő kiadást. Az egyes változatok opciókban eltérnek egymástól, hardveres és szoftveres korlátozásokat tartalmazhatnak, licenszeik árban és licenszelési politikában is jelentősen eltér egymástól. Legyen körültekintő a kiválasztás során!  „Enterprise Edition”: teljes funkcionalitást biztosító kiadás;  „Standard Edition”: közel teljes funkcionalitást biztosító kiadás, de bizonyos funkciókat (pl.: particionálás) nem támogat, középvállalati rendszerek számára tervezték;

Kiadás: 2014.08.07.

Verzió: 3.10




 „Standard Edition One”: funkcionalitásban megegyezik a „Standard Edition”-nel, de hardveres korlátozásokat tartalmaz (pl.: csak legfeljebb 2 processzoros gép esetén használható), kisvállalati rendszerek számára tervezték;  „Personal Edition”: fejlesztők számára készített 1 felhasználót támogató kiadás, hardveres korlátozásokkal, intézményi üzemre nem alkalmas. Az egyes kiadások licenszelési módjairól, korlátozásaikról, funkcióbeli eltéréseikről és áraikról az Oracle partnerüktől, viszonteladójuktól érdeklődhetnek! A kiadás kiválasztása után a „Következő”-re kattintva léphet tovább.

Az Oracle rendszer könyvtárainak megadása következik. Egy „Oracle Base” és egy „Software Location” könyvtárat kell megadnunk. Ha ezek a könyvtárak még nem léteznek, a telepítő létrehozza őket. Az „Oracle Base” könyvtárban fogja a telepítő a rendszert felépíteni, az aktuálisan telepítendő példány pedig a „Software Location” könyvtárba fog kerülni. A könyvtárak megadása után lépjen a tovább a „Következő” gombbal!

Kiadás: 2014.08.07.

Verzió: 3.10




A következő képernyőn egy folyamatkijelzőn követheti nyomon a telepítő által végzett ellenőrzések (hardver, szoftver, szabad terület, stb.) folyamatát, az teljesen automatizáltan zajlik, felhasználói beavatkozást nem igényel. Ha elkészült vele, aktívvá válik a „Következő” gomb, tovább léphet.

A sikeres ellenőrzés után egy riportot generál, amit a „Save response file” gombra kattintva elmenthet. A riportban egy összefoglalót talál az eddigi beállításokról. A „Befejezés” gombra kattintva haladjon tovább!

Kiadás: 2014.08.07.

Verzió: 3.10




A rendszer tényleges telepítését elvégzi a telepítő, ezen az oldalon is egy folyamatkijelző látható. Ha részletesebben szeretné látni a telepítés folyamatát, a „Details” gombra kattintva egy ablakban nyomon követheti, mely komponenseket telepítette fel eddig, és sikeres volt-e az egyes komponensek telepítése. Ha a folyamat végét elérte a telepítő, már csak a záró képernyőre vált át a telepítő.

Kiadás: 2014.08.07.

Verzió: 3.10




A záró képernyőn ideális esetben a „The installation of Oracle Database was successful.” üzenetnek kell megjelennie, ezzel kész az Oracle alaprendszer telepítése. Ha a telepítés során hiba lépett fel, a pontos hibaüzenetet is itt fogja a telepítő megjeleníteni. Ezzel a kezelőszoftver telepítése megtörtént, és elérhetővé válnak a különböző futtatható alkalmazások, amelyek segítségével lehetőségünk van a további lépések elvégzésére.

2.1.1.2. Listener telepítés A telepítés következő fázisa a „LISTENER” (figyelő) telepítése, és konfigurálása. A figyelő telepítéséhez indítsuk el az „Oracle Net Configuration Assistant” programot, melyet a menüből a Start/Programs/Oracle-[ORACLE_HOME]/Configuration and Migration Tools/Net Configuration

Assistant

helyen

érünk

el,

vagy

a

parancssorból

váltsunk

az

ORACLE_HOME\bin könyvtárára és indítsuk el a netca.bat állományt. Első lépésben válasszuk a „Listener Configuration” pontot majd kattintsunk a „Következő” gombra!

Válasszuk az „Add” pontot és kattintsunk a „Következő” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




A következő ablakon adjuk meg a figyelő nevét, ami jelen esetben a LISTENER legyen, majd kattintsunk a „Következő” gombra.

Válaszuk ki a kommunikációs protokollt (jelen esetben TCP-t), majd kattintsunk a „Következő” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




Állítsuk be a figyelő port-ját melyen, a későbbiekben majd el tudjuk érni azt, az alapértelmezett érték a 1521-es port, de ettől eltérő értéket is választhatunk. Természetesen ebben az esetben a kliens oldali telepítésnél is ezt kell szem előtt tartani. Ha beállítottuk a port-ot, kattintsunk a „Következő” gombra.

Ha további figyelőt nem szeretnénk beállítani, akkor válaszuk a „No” pontot, majd kattintsunk a „Következő” gombra.

Ezzel elkészült az figyelő szolgáltatásunk, mely az adatbázishoz irányuló kéréseket fogja továbbítani. Kattintsunk a „Következő” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




Ezzel visszakapjuk az első oldalt, melyen a „Befejezés” gombra kattintva tudjuk a konfiguráló programot bezárni.

2.1.1.3. Adatbázispéldány létrehozása A telepítés következő fázisa az adatbázis létrehozása. Adatbázis létrehozásához használjuk a „Database Configuration Assistant” programot, melyet a menüből a Start/Programs/Oracle[ORACLE_HOME]/Configuration

and

Migration

Tools/DatabaseConfiguration

Assistant helyen érünk el, vagy a parancssorból váltsunk az ORACLE_HOME\bin könyvtárára és indítsuk el a dbca.bat állományt. Az üdvözlő képernyőn kattintsunk a „Következő” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




Második lépésként válasszuk ki az „Create a Database” pontot, majd kattintsunk a „Következő” gombra.

A következő lépésben választhatunk, hogy milyen jellegű adatbázist szeretnénk telepíteni. Mivel a háromrétegű Neptun adatbázis leginkább az OLTP rendszerű adatbázisokhoz hasonlít, így válasszuk ki a „Transaction Processing” sablont. A későbbiekben, ha elmentjük az általunk készített adatbázis sablonját, akkor az is megjeleníthető a listában. A választás után kattintsunk a „Következő” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




Harmadik lépés az adatbázis egyedi nevének megadása. A felületen a „Global Database Name” részt kell kitölteni, amely hatására a „SID” automatikusan kitöltődik. A név megadás után kattintsunk a „Következő” gombra.

A negyedik lépésben pipáljuk be a „Configure the Database with Enterprise Manager” jelölőnégyzetet, ami telepíteni fogja az adatbázisunkba az Enterprise Manger-t, aminek segítségével a későbbiekben adminisztrálhatjuk az adatbázisunkat. Ezen a felületen engedélyezzük és konfiguráljuk be az „Enable Email Notifications”-t. Adjunk meg egy elérhető smtp szervert („Outgoing Mail (SMTP) Server”) és egy email címet („Email Address”). Ezt a beállítást későbbiekben is el tudjuk végezni az Enterprise Manager segítségével. A beállítások után kattintsunk a „Következő” gombra. Kiadás: 2014.08.07.

Verzió: 3.10




A következő ablakon állítsuk be a SYS, SYSTEM, DBSNMP, SYSMAN felhasználókhoz tartozó jelszavakat. Lehetőségünk van az összes felhasználóhoz egy jelszót megadni („Use the Same Password for All Accounts”). A jelszómegadás után kattintsunk a „Következő” gombra!

A hatodik lépésben azt kell meghatározni, hogy az adatok tárolásához és a rendszer működéséhez szükséges fájlok milyen típusú háttértárolóra kerüljenek. Ha korábban nem konfiguráltunk ASM rendszert, akkor válasszuk a hagyományos „File System” pontot, ami azt jelenti, hogy az adatbázishoz kapcsolódó fájlok az operációs rendszer által használt és karbantartott meghajtókra fognak kerülni. A választás után kattintsunk a „Következő” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




A hetedik lépésben az adatbázis fájlok helyének megadását választhatjuk ki. Az egyszerűbb és gyorsabb telepítés érdekében válasszuk a „Use Oracle-Managed Files” pontot és az ajánlást betartva adjunk meg legalább két külön lemezen elhelyezett elérést a kontroll és online naplófájlok tükrözésére. Kattintsunk a „Multiplex Redo Logs and Control Files…” gombra és állítsunk be két elérési utat. A beállítást követően minden fájl a megadott helyekre fog létrejönni az Oracle által generált nevekkel. A „File Location Variables…” gombra kattintva megnézhetjük milyen elérési utak vannak beállítva

és

ezeket

is

felhasználhatjuk

a

leírásban.

Ilyen

út

lehet

például

a

{ORACLE_BASE}/oradata/{DB_NAME}. A beállítások után kattintsunk az „OK” majd a „Következő” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




A következő felületen a Flash Recovery, illetve az Archive Log beállításait végezhetjük. Mindkét funkció opcionális. A Flash Recovery segítségével egy olyan funkció válik elérhetővé mely segítségével egy előre megadott ideig a törölt, módosított adatok visszaállíthatóak, illetve az eldobott táblák is egy „Recycle Bin” területre kerülnek. Az Archive Log engedélyezésével az online naplóállományok a felülírás előtt elmentődnek a beállított helyre, mely segítségével egy adatsérülés vagy adatvesztés esetén időkiesés nélküli helyreállítás lehetséges. A funkciók beállítása intézményi döntés, de mindkettő erősen ajánlott. Jelöljük be a „Specify Flash Recovery Area” jelölőnégyzetet és adjunk meg egy elérési utat („Flash Recovery Area”) valamint egy maximális méretet („Flash Recovery Area Size” 4GB). Az Archive Log üzemmódhoz jelöljük be a „Enable Archiving” jelölőnégyzetet, majd kattintsunk az „Edit Archive Mode Parameters…” gombra. Ezek után a felugró párbeszédablakon jelöljük be az „Automatic Archiving” jelölőnégyzetet, az „Archive Log File Format” szerkesztőben adjuk meg az ’ARC%S_%R.%T’ maszkot, majd az „Archive Log Destinations” hálón adjunk meg legalább két különböző elérési utat. A beállítások után kattintsunk az „OK” majd a „Következő” gombra.

A kilencedik lépésben lehetőségünk van SQL scriptek megadására, melyek az adatbázis létrehozása után automatikusan futtatásra kerülnek. Itt célszerű megadni azokat a scripteket melyek létrehozzák a táblatereket és felhasználókat. A scriptek tartalmát a későbbiekben részletesen tárgyaljuk, ezekből célszerű egy olyan scriptet összeállítani, ami minden táblateret és felhasználót elkészít. A scriptnél figyelembe kell venni, hogy SYS felhasználó fogja futtatni, így az egyes objektumoknál szükséges a séma megadása. A lefuttatandó scriptek felvételéhez kattintsunk az „Add” gombra, majd tallózzuk ki a korábban elkészített fájlt. Ha minden futtatni kívánt fájlt felvettünk, kattintsunk a „Következő” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




A következő lépésben az inicializációs értékek beállítása következik. A „Memory” fülön válasszuk a „Custom” pontot majd a „Shared Memory Management” opciónál válasszuk az „Automatic” pontot. Az SGA méretét változtassuk 2000 MB-ra míg a PGA méretét állítsuk 600 MB-ra. Az itt leírt beállítások az intézmény által rendelkezésre bocsátott szerver paramétereitől illetve a kezelt adatok mennyiségétől függően változhatnak.

A „Sizing” fülön állítsuk a „Processes” értékét 450-re. Ennek a paraméternek az értékét minden esetben az alkalmazás és web szerverekhez kell igazítani. Általánosan igaz, hogy szerverenként 100 felhasználói folyamattal számoljunk, plusz 50 a rendszerfolyamatok számára. Pl.: 1 alkalmazás szerver, 2 hallgatói web, 1 oktatói web ~ 450. A sessions paraméter értéke alapesetben az itt beállított érték 1,1 szerese lesz, azaz jelen esetben 495. Kiadás: 2014.08.07.

Verzió: 3.10




A „Character Sets” fülön állítsuk be az adatbázisunk karakterkészletét „Database Character Set” ’EE8MSWIN1250’ –re, a „National Character Set” értékét ’AL16UTF16- Unicode’ –ra, a „Default Language” ’Magyar’ illetve a „Default Date Format” –ot ’Magyarország’ értékre.

A „Connection Mode” fülön állítsuk be a „Dedicated Server Mode” pontot. A további ajánlott paraméterek beállításához kattintsunk az „All Initialization Parameters…” gombra, és a következő paramétereket ellenőrizzük: db_file_multiblock_read_count ...............................................................................8 open_cursors.........................................................................................................350 processes...............................................................................................................450 sessions .................................................................................................................495

Kiadás: 2014.08.07.

Verzió: 3.10




db_writer_processes ............................................................ 1(8 processzoronként 1) undo_management .............................................................................................. auto optimizer_mode............................................................................................ all_rows cursor_sharing ................................................................................................ similar session_cached_cursors ..........................................................................................60 db_recovery_file_dest_size ...............................................................4G (opcionális) undo_retention ............................................................................... 1800 (opcionális) A beállítások elvégzése után kattintsunk a „Következő” gombra.

A következő lépés során az online naplócsoportok konfigurálása következik. A REDO csoportok méretét meg kell változtatni 200 MB méretűre, és összesen 5 csoportot kell létrehozni. A méret változtatását a „File Size” paraméter átállításával, míg új csoportot a „Create” gomb megnyomásával hozhatunk létre. A csoporton belüli tagok megadása nem szükséges, ha a korábbiakban ajánlott „Use Oracle-Managed Files” pontot választottuk. A beállítások elvégzése után kattintsunk a „Következő” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




Az utolsó lépésben jelöljük be a „Create Database” és a „Save as a Database Template” jelölőnégyzeteket, ami elkészíti a bekonfigurált adatbázist és a konfigurációt elmenti az általunk megadott névvel. Ez a template egy XML fájl lesz, ami mozgatható a szerverek között. A beállítások elvégzése után kattintsunk a „Befejezés” gombra.

A telepítés befejezése után egy összegző ablakot kapunk az adatbázis és a hozzá tartozó Enterprise Manager elérhetőségéről. A létrejött felhasználók jelszavát és zárolását tudjuk megváltoztatni a „Password Management” gombra kattintva. Az alkalmazás lezárásához kattintsunk az „Exit” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




Az adatbázis elkészítése után ellenőrizzük az Enterprise Manager működését, illetve a belépést követően ellenőrizzük a beállított paraméterek helyességét. Amennyiben szükséges gondoskodjunk az Enterprise Manager működési port-jának a megfelelő üzemeltetői gépekre történő engedélyezését. Ellenőrizzük, illetve ha ezt a telepítésnél nem tettük meg akkor állítsuk be az email küldő szolgáltatást és változtassunk az intézmény által megkövetelt metrikák szintjén.

2.1.1.4. Táblaterek kialakítása Oracle adatbázis-kezelő rendszeren Az Oracle adatbázis-kezelő rendszer az adatokat és indexeket táblaterekben tárolja. A táblatér egy vagy több fájlból álló előre definiált egység. A táblaterek és az azokban elhelyezett adatok kialakításának fontos szerepe van az adatbázis-kezelő későbbi teljesítményében ezért átgondolt tervezésük ajánlott. A Neptun.NET egységes tanulmányi rendszer adatainak elhelyezésére a következő egy „NEPTUN3R_DAT” táblaterek kialakítása ajánlott, nagy intézményi adatbázis esetén az SDA-val egyeztetve akár több táblatér is kialakításra kerülhet! A teszt rendszer adatait mindig tároljuk külön táblatérben, vagy lehetőség szerint külön adatbázispéldányban vagy adatbázis szerveren. A táblaterek méretének megválasztásánál fontos szempont a tárolandó adatmennyiség. Új rendszer indításakor a hallgatói létszám alapján kell kalkulációt készíteni a táblaterek méretezéséhez, ehhez az SDA munkatársaitól kérhet segítséget!

Kiadás: 2014.08.07.

Verzió: 3.10




2.1.1.5. Adatfájlok kialakítása a táblaterekhez Az Oracle adatbázis-kezelő rendszerben egy táblatérhez több adatfájlt rendelhetünk. Ezen adatfájlok méreteinek összege a korábbi számítások alapján kapott érték legyen, hogy az első betöltés alkalmával az adatblokkok rendezett állapotban legyenek a meghajtón. Az adatfájlokat a táblatér létrehozásával egy időben egy paranccsal végezzük. A parancsban megadott elérési útnak érvényesnek kell lennie, és rendelkezni kell elegendő kapacitással az adott meghajtón. A létrehozáskor lehetőség van a kezdeti méreten felül automatikus növekedési értéket beállítani, mely akkor aktivizálódik, ha a táblatérben tárolni kívánt adatoknak nem áll rendelkezésre hely az adott adatfájlban. A növekedés mértékét korlátozhatjuk egy maximális értékkel vagy azt is beállíthatjuk, hogy korlátlanul növekedjen. Ebben az esetben a rendelkezésre álló lemezkapacitás az, ami meghatározza az adatfájl legnagyobb méretét. Természetesen, ha a rendelkezésre álló területnél nagyobb maximális értéket állítottunk be, akkor is a rendelkezésre álló hely fogja megszabni a határt. A táblatér maximális méretét mindig a lemezkapacitás alá állítsuk be, hogy az esetleges helyhiány esetén legyen még hova növelni. Egy táblatérhez a későbbiekben is tudunk új adatfájlokat rendelni, akár másik lemezegységről is.

Táblaterek létrehozásánál használt kapcsolók: [LOGGING/NOLOGGING] azt határozza meg, hogy a táblatérben tárolt objektumok generáljanak UNDO illetve REDO bejegyzéseket. Az alapértelmezett a LOGGING. A táblatérben elhelyezett objektumokra egyesével is definiálhatjuk ezt a táblatér beállításától függetlenül. [ONLINE/OFFLINE] a táblatér létrehozása után azonnal használható, ha ONLINE –ra állítjuk, ellenkező esetben a táblatérbe nem lehet adatokat elhelyezni, módosítani. [EXTENT MANAGEMENT LOCAL/DICTIONARY AUTOALLOCATE/UNIFORM] A táblaterekben lévő kiterjesztéseket nyilvántarthatjuk adatszótár táblában egy bittérkép segítségével. Amikor egy táblateret létrehozunk, akkor ezen két módszer közül választhatunk. Később már nem módosíthatjuk a nyilvántartási módot. A LOCAL kulcsszó arra utal, hogy a táblatér meta adatait is a táblatérben tároljuk, a DICTIONARY –nél pedig ezen információk az adatszótárban találhatók. A táblaterek létrehozásához használjuk a következő parancsokat:

Kiadás: 2014.08.07.

Verzió: 3.10




NEPTUN_DAT táblatér létrehozása 3 darab 2GB-os kezdeti méretű adatfájllal, fájlonként 100 MB-os növekedéssel és 10GB-os maximális mérettel. A fájlok neve, kiterjesztése és elérési útja szabadon választott, de érdemes valamilyen szabály alapján elnevezni őket. A példa Windowsos fájlrendszeren mutatja be a kialakítást. A táblatér létrehozása más rendszeren is ilyen formán történik, természetesen a fájlok elérési útjának megfelelő módon történő megadásával! SQL> -- Neptun3R táblatér létrehozása SQL> -- Connect sys as sysdba SQL> CREATE TABLESPACE NEPTUN3R_DAT DATAFILE SQL> 'C:\ORADATA\NEPTUN3R_DAT001.DBF' SIZE 2048M AUTOEXTEND ON NEXT 100M MAXSIZE 10240M, SQL> 'C:\ORADATA\NEPTUN3R_DAT002.DBF' SIZE 2048M AUTOEXTEND ON NEXT 100M MAXSIZE 10240M, SQL> 'C:\ORADATA\NEPTUN3R_DAT003.DBF' SIZE 2048M AUTOEXTEND ON NEXT 100M MAXSIZE 10240M SQL> LOGGING SQL> ONLINE SQL> EXTENT MANAGEMENT LOCAL AUTOALLOCATE SQL> BLOCKSIZE 8K SQL> SEGMENT SPACE MANAGEMENT AUTO SQL> FLASHBACK ON;

2.1.1.6. Sémák kialakítása Az Oracle adatbázis-kezelő rendszer az egy felhasználóhoz tartozó objektumok összességét sémának nevezi. A séma kialakításánál fontos tényező az alapértelmezett táblaterek megadása illetve a megfelelő jogosultságok és szerepkörök beállítása. A Neptun Egységes Tanulmányi rendszer az alapértelmezés szerint egy adatbázis sémát használ. A felhasználók azonosítása és jelszóellenőrzése az alkalmazás szerver része. A séma elnevezése szabadon választható, de célszerű a NEPTUN3R nevet választani, amit a kiajánlott létrehozó scriptek is használnak. A NEPTUN3R felhasználó létrehozását a következő script segítségével történik: SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL>

-- NEPTUN3R felhasználó létrehozása -- Connect sys as sysdba CREATE USER NEPTUN3R IDENTIFIED BY PA$$WORD DEFAULT TABLESPACE NEPTUN3R_DAT TEMPORARY TABLESPACE NEPTUN3R_TMP PROFILE DEFAULT ACCOUNT UNLOCK;

A tárolt adatok megnövekedése illetve a gyakori adatváltoztatások miatt, az adatbázisok jelentős részét teszik ki az adatváltozások és rendszerinformációk naplózásra szolgáló táblák. Annak érdekében, hogy érdemi információkat tartalmazó adatokat jól elszeparáljuk az adattörténetet leíró naplóktól, azok számára külön séma kialakítása ajánlott. Mivel ebben a sémában az idő előrehaladásával a valós adatmennyiség többszöröse keletkezik, így a

Kiadás: 2014.08.07.

Verzió: 3.10




naplózásra szolgáló séma adatait külön táblatérbe helyezzük el. A naplózási sémában lévő táblákra szinonimák létrehozása szükséges, hogy a rendszer továbbra is elérje ezeket a táblákat. A szinonimákon felül a select és insert jogosultságokat kell megadni az érintett táblákra. A naplózási séma ajánlott neve NEPTUN3R_LOG melynek létrehozása a következő script segítségével történik: SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL>

-- NEPTUN3R_LOG felhasználó létrehozása -- Connect sys as sysdba CREATE USER NEPTUN3R_LOG IDENTIFIED BY PA$$WORD DEFAULT TABLESPACE NEPTUN3R_LOG TEMPORARY TABLESPACE NEPTUN3R_TMP PROFILE DEFAULT ACCOUNT UNLOCK;

2.1.1.6.1. Egyedi PROFILE alkalmazás A felhasználó létrehozásánál a default profil került alkalmazásra. Az Oracle adatbázis-kezelő rendszerben a profilok segítségével erőforráskorlátokat állíthatunk be. Mivel az alapértelmezett profilban végtelenre van beállítva egy munkamenet tétlensége, így könnyen előfordulhat a rendszerünkben olyan session mely mögött már tényleges tranzakció nincs. Ilyen helyzet alakulhat ki, ha a hálózati kapcsolat megszakad, vagy végzetes kivétel történik az alkalmazás vagy web szerver oldali Oracle kliensben. Az ilyen session-ok általában lezárt állapotban vagy kommit-ált, vagy rollback-elt állapotban maradnak és semmilyen zavart nem okoznak a rendszer működésében, csak feleslegesen foglalnak egy sessiont. Előfordulhat viszont az is, hogy olyan session szakad le melyben lezáratlan tranzakció marad, melynek hatására hossza várakozási fa, vagy holtpont alakulhat ki. Az ilyen és ehhez hasonló helyzetek feloldására megoldás lehet egy egyedi profil kialakítása, melyet a NEPTUN3R felhasználóhoz rendelünk. A profil elkészítése és felhasználóhoz rendelése a következő módon történik: SQL> -- NEPTUN3R Profile létrehozása SQL> -- Connect sys as sysdba SQL> CREATE PROFILE NEPTUN3R_PROFILE LIMIT PASSWORD_LIFE_TIME UNLIMITED IDLE_TIME 15; SQL> ALTER USER NEPTUN3R PROFILE NEPTUN3R_PROFILE;

Az így létrehozott profil segítségével a 15 percnél hosszabb ideig tétlenül váró munkamenetek automatikusan visszagörgetéssel befejeződnek, illetve a felhasználói jelszó lejáratát kikapcsoljuk. (Alapértelmezetten 180 nap után járna le.) Ez a normális működésben nem okoz zavart, mert a szerver által valóban használt munkamenetek sosem lesznek ennyi ideig tétlenek.

Kiadás: 2014.08.07.

Verzió: 3.10




2.1.1.7. Adatbázis létrehozása template segítségével Az Oracle adatbázis-kezelő rendszer telepítésénél lehetőségünk van arra, hogy az egyedi példánykonfigurálás helyett egyelőre elkészített adatbázis minta alapján készítsük el azt. Az adatbázis minta tartalmazza a példány főbb paramétereinek beállítását, valamint létrehozza a táblatereket és felhasználókat. A template használatával jelentős idő takarítható meg az adatbázis telepítésénél. Mivel nincs két egyforma környezet ezért az SDA Informatika Zrt. előre elkészített adatbázismintát nem ad ki, de az intézményeknek ajánlott a telepítés alkalmával elkészíteni azt, hogy egy tesztrendszer kialakításánál vagy egy új szerverre történő költözés alkalmával ne kelljen minden paramétert újra beállítani.

2.1.2. Microsoft SQL Server A telepítés megkezdése előtt ellenőrizzük a következő beállításokat. A területi és nyelvi beállításoknál a magyar nyelv legyen beállítva. Start\Settings\Control Panel\Regional and Language Options

A beállítások ellenőrzése után, kezdjük el az MSSQL Adatbázis Szoftver telepítését. A telepítés megkezdéséhez váltsunk a telepítőkészlet könyvtárára és indítsuk el a setup.exe állományt.

Kiadás: 2014.08.07.

Verzió: 3.10




Az MSSQL telepítő-csomag gyökérkönyvtárában található „setup.exe” elindítása után ezt a kezdőoldalt láthatjuk. Itt kattintson az „Installation” linkre, innen érhetőek el a telepítési opciók. A telepítési leírást teljes részletességgel készítettük, kézenfekvő részletek is kifejtésre kerültek.

Kiadás: 2014.08.07.

Verzió: 3.10




A felkínált lehetőségek közül válasszuk ki a „New installation or add features to an existing installation” menüpontot. Ha későbbiekben az MSSQL szerver konfigurációját szeretnénk módosítani, szintén ezt a menüpontot kell majd választanunk. Ezután a telepítő ellenőrzéseket fog végezni, majd a következő képernyőt fogja megjeleníteni.

A képernyőn meg fog jelenni egy összesítés az elvégzett ellenőrzésről: „Passed / Failed /Skipped / Warning”. („Megfelelt / Nem felelt meg / Figyelmeztetés / Kihagyva”). A „Show details” gombra kattintva a részleteket is megtekintheti, ami ajánlott, ha nem volt minden tétel „Passed”, így informálódhat az esetleges problémákról. Figyelmeztetés vagy hiba esetén olvassa el a „Status” alatt leírtakat, és kövesse az instrukciókat! Ha minden tétel megfelelő, az „OK” gomb megnyomásával folytathatja a telepítést.

Kiadás: 2014.08.07.

Verzió: 3.10




A következő képernyőn a rendszer a telepítéshez kéri az MSSQL szerver termékkulcsát, a kulcs tagolását automatikusan elvégzi. A termékkulcs megadása után a „Next” gomb megnyomásával folytathatja a telepítést.

Kiadás: 2014.08.07.

Verzió: 3.10




A felhasználási feltételeket az „I accept the license terms” jelölőnégyzetet bepipálva fogadhatja el. A „Send feature usage data to Microsoft…” jelölőnégyzet bepipálásával engedélyt adhatunk a telepítőnek, hogy konfigurációval kapcsolatos adatokat küldjön a Microsoft felé. Ez utóbbi nem feltétele a telepítés folytatásának. Kattintson a „Next” gombra!

A következő képernyőn a telepítő előkészítését végzi el, az „Install” gombra kattintva folytathatja a telepítési folyamatot.

Kiadás: 2014.08.07.

Verzió: 3.10




A telepítő előkészítéséről is értesíti a felhasználót egy összefoglaló sorral: „Passed / Failed /Skipped / Warning”. A „Show details” gombra kattintva a részleteket is megtekintheti, ami ajánlott, ha nem volt minden tétel „Passed”, így informálódhat az esetleges problémákról. Figyelmeztetés vagy hiba esetén olvassa el a „Status” alatt leírtakat, és kövesse az instrukciókat! Ha minden tétel megfelelő, az „OK” gomb megnyomásával folytathatja a telepítést.

Kiadás: 2014.08.07.

Verzió: 3.10




A „Setup Role” szekcióban választhatjuk ki, hogy milyen alapbeállításokkal, komponensekkel készítse elő a telepítést. Az „SQL Server Feature Installation” -t válassza ki, majd a „Next” gombra kattintva folytassa a folyamatot!

Kiadás: 2014.08.07.

Verzió: 3.10




A következő lépésben a telepítendő szerepköröket és komponenseket választhatja ki. A felajánlott lehetőségek közül ajánljuk a kiválasztásra a következőket:  „Database Engine Services”: az adatbázis-kezelő motorja, feltétlenül szükséges,  „Client Tools Connectivity”: klienseszközök, az adatbázis elérését biztosítják,  „Management tools – Basic és Complete”: adminisztrációs és kezelő eszközök. A működéshez ezek a szükséges komponensek, ha más rendszerek további komponenseket is megkövetelnek, az illető rendszerek dokumentációjából tájékozódhat. Kattintson a „Next” gombra!

Ismét egy összefoglalót láthat, amennyiben van figyelmeztetés, vagy hiba, a „Show details” gombra kattintva tájékozódhat. Amennyiben nem volt, a „Next”-re kattintva lépjen tovább a folyamatban!

Kiadás: 2014.08.07.

Verzió: 3.10




Ezután az adatbázisszerver-példány („instance”) létrehozása következik. Az egyes példányok elkülönítve, egymástól függetlenül futnak, erőforrás-allokáció is példányonként történik. A lap tetején található rádiógombokkal („Default Instance” és „Named Instance”) kiválaszthatja a példány nevét. A „Default instance”-t választva a példány neve „MSSQLSERVER” lesz. A névhez tartozik egy „Instance ID” is, ezt célszerű ugyanarra a névre választani, illetve megadhatunk egy „Instance root directory”-t, ebbe a könyvtárba fogja a példányhoz tartozó állományokat helyezni a telepítő. Ha több SQL szerver példányt szeretnénk futtatni, ajánlott „beszédes” nevet megadni a „Named Instance” létrehozásakor. Amennyiben a telepítő talált az adott gépen már létező MSSQL szerver-példányokat, az „Installed instances” listában felsoroja azokat. A „Next” gomb megnyomásával lépjen tovább!

Kiadás: 2014.08.07.

Verzió: 3.10




A következő oldalon ellenőrzi a telepítő a lemezterületet. Megjeleníti, hogy az egyes meghajtóinkon mennyi szabad terület áll rendelkezésre, illetve az MSSQL mennyi területet igényel azon a meghajtón. Amennyiben a szükséges lemezterület rendelkezésre áll, a „Next” gomb megnyomásával folytassa a folyamatot!

Kiadás: 2014.08.07.

Verzió: 3.10




Ezután a példány konfigurálása következik, itt figyeljünk, hogy több „Tab” („lapfül”) van az oldalon. A „Service Accounts” fül alatt megadhatjuk, hogy az egyes szolgáltatások mely felhasználók nevében fussanak, csak létező fiókot adhatunk meg. A beépített „System” és „Network service” rendszerfiókok az „Account Name” oszlop celláira kattintva választhatóak ki egy lebegőmenüből, de ha egy valós felhasználó nevében szeretnénk futtatni az egyes szolgáltatásokat, a „<>” menüpontra kattintva választhatjuk ki. Javasoljuk a beépített rendszerfiókok használatát:  „SQL Server Agent”: „network service”,  „SQL Server Database Engine”: „System”. Ha valós felhasználó nevében futtatjuk az adatbázisszervert, a felhasználó jelszavát is meg kell adnia a „Password” oszlopban! A „Startup Type” oszlopban adhatjuk meg az egyes szolgáltatások indítási módját. Ajánlott az operációs rendszerre bízni az indítás legalább az „SQL Server Database Engine” esetében, ezt az „Automatic” opció kiválasztásával teheti. Kattintson át a „Collation” lapfülre!

Kiadás: 2014.08.07.

Verzió: 3.10




Amennyiben magyar területi beállításokat használunk az operációs rendszeren, automatikusan fel fogja ajánlani a telepítő a „Hungarian_CI_AS” lehetőséget, ha nem, a „Customize…” gombra kattintva válassza ki!  „Hungarian”: magyar nyelvi (közép-európai) karakterkészlet,  „CI”: a „Case Insensitive” – kis/nagybetűre nem érzékeny rendezéskor,  „AS”: „Accent Sensitive” – az ékezetes karaktereket is besorolja ABC-helyesen. Ha a beállítás helyes, a „Next”-re kattintva lépjen tovább!

Az adatbázis-motor beállítása következik. Ezen a lapon is több „fül” található! Adja meg a hitelesítés módszerét („Authentication Mode”):  „Windows autentication mode”: az operációs rendszer hitelesítsen minden felhasználót,  „Mixed Mode”: operációs rendszer felhasználók és SQL szerver saját felhasználói is bejelentkezhetnek. Válassza a „Mixed mode”-t! Meg kell adnia a beépített „sa” („system administrator”, azaz „rendszer adminisztrátor”) felhasználónak egy jelszót és jelszóismétlést. Az „sa” a legmagasabb jogú adatbázis-felhasználó, neki lesz joga az adatbázis-kezelőn bármilyen műveletet végrehajtani.

Kiadás: 2014.08.07.

Verzió: 3.10




Windows (vagy tartományi) felhasználókat is hozzáadhatunk az SQL szerver „Administrators” jogú felhasználói közé, amit célszerű is megtenni – vegye fel a rendszer-üzemeltető személyeket! Kattintson a „Data Directories” fülre!

A „Data Directories” fül alatt adhatjuk meg az elérési utakat az egyes könyvtárakhoz. Ha nem egy meghajtóra, vagy nem az alapértelmezett könyvtárszerkezetbe szeretnénk elhelyezni az adatállományokat, az egyes adatállomány-típusokhoz egy könyvtártallózó segítségével adhatjuk meg a helyüket:  „Data root directory”: gyökérkönyvtár az állományok számára,  „User database directory”: felhasználói adatbázis-állományok helye,  „User database log directory”: felhasználói adatbázisnaplók helye,  „Temp DB directory”: temp („ideiglenes”) adatbázis helye,  „Temp DB log directory”: temp („ideiglenes”) adatbázis naplóállományok helye,  „Backup directory”: mentések könyvtára. Az adatbázisok létrehozásakor lehetőség lesz ezektől a könyvtáraktól eltérő könyvtárba is elhelyezni az adatbázis-állományokat és logokat. A kiválasztott könyvtárakra az SQL szervert futtató felhasználónak írási joggal kell rendelkeznie!

Kiadás: 2014.08.07.

Verzió: 3.10




A könyvtárak kiválasztása után a „Next”-re kattintva léphet tovább.

Újabb ellenőrzést végez a telepítő, amelyről egy összegzést jelenít meg, a „Show details” gombra kattintva természetesen itt is lehetőség van megtekinteni a részleteket. „Next”-re kattintva lépjen tovább!

Kiadás: 2014.08.07.

Verzió: 3.10




Egy végső összesítést készít számunkra a telepítő, itt már nincs lehetőség paraméterek változtatására, illetve ezeket az információkat egy „ConfigurationFile.ini” állományba el is menti. A későbbiekben ebből az állományból szerezhetünk információt a példányunkról. Az „Install” gombra kattintva a tényleges telepítés elindul, teljesen automatikus a folyamat. Egy folyamat-kijelzőn nyomon követhetjük a telepítés állapotát.

A telepítés végeztével a fent látható ábra fog megjelenni. Tájékoztat a telepítés sikerességéről – vagy esetleges sikertelenségéről. Érdemi információt a lap tetején látható „Summary log” telepítési naplóállományból szerezhetünk szükség esetén. A „Close” gombbal zárható be a telepítő program.

2.1.2.1. Login létrehozása a Neptun3R tanulmányi rendszer adatbázisához Mivel a Neptun3R tanulmányi rendszer kapcsolatleírójában, csak a felhasználónév/jelszó megoldás támogatott, így a működéshez szükségünk lesz egy olyan felhasználóra, aki jogosult belépni az adatbázis kezelőre. A login létrehozásához használjuk a Microsoft SQL Server Management Studio alkalmazását. A kezdéshez menjünk a Start/Programs/Microsoft SQL Server 2005/ Microsoft SQL Server Management Studio majd indítsuk el az alkalmazást. A

Kiadás: 2014.08.07.

Verzió: 3.10




belépéshez adjuk meg az ’sa’ felhasználót és a telepítésnél megadott jelszót vagy használjunk Windows autentikációt, majd kattintsunk a „Connect” gombra.

„Servername”-nek adja meg az adatbázis kiszolgáló nevét vagy IP címét! Amennyiben több adatbázis példány is fut rajta, akkor „\” jellel elválasztva a példány nevét is. Ha a kiszolgálóra van bejelentkezve konzolon vagy távoli asztallal, akkor a „localhost” nevet is megadhatja! „Authentication”-nak válassza a „Windows Authentication”-t, ha olyan Windows- vagy domain felhasználó nevével van bejelentkezve, akinek a telepítéskor (vagy később) „sysadmin” szerepkört adott. Ha nincs ilyen felhasználó, vagy nem az ő nevével van bejelentkezve, akkor az „SQL Server Authentication”-t válassza, és adja meg egy „sysadmin” szerepkörű felhasználó nevét és jelszavát. Az SQL Server alapértelmezett „sysadmin” jogú felhasználója a „sa”. Ha megadta az adatokat, kattintson a „Connect” gombra! Bejelentkezés után egy management felületet kap, amely 3 részre van osztva:  menüsáv: az ablak tetején elhelyezkedik el, fontosabb funkciók, és parancsgombokat tartalmaz;  objektumtallózó: a képernyő bal oldalán helyezkedik el, egy kibontható fa-struktúrában tartalmazza az adatbázispéldány alá tartozó adatbázisokat (és annak az objektumait csoportosítva), a biztonsági objektumokat, a szerverobjektumokat, stb;  munkaterület: a képernyő jobb oldali területe, a kiválasztott funkciókhoz tartozó felületek töltődnek be ide.

Kiadás: 2014.08.07.

Verzió: 3.10




Első lépésben a telepíteni kívánt projekthez (Neptun, Poszeidon, Unipoll, Teszt-Neptun, TesztPoszeidon, Teszt-Unipoll) hozzon létre felhasználót!

Nyissa le az adatbázis példány alatti fát, és az alatt a „Security” csomópontot is. Itt találhatja a „Logins” csomópontot. Kattintson rá jobb gombbal, majd a megnyíló lebegőmenüben kattintson a „New Login” menüpontra!

Kiadás: 2014.08.07.

Verzió: 3.10




A felhasználó adatainál a „General” lapon először adjon meg egy egyedi felhasználónevet („Login name”), célszerű olyan nevet választani, ami utal a projekt funkciójára is! (pl.: „Neptun3r”, „Unipoll_teszt”, stb…). Két rádiógomb következik, amelyek a beléptetés módját határozzák meg, itt az „SQL Server Authentication”-t jelölje ki, és adjon meg a felhasználónak jelszót, jelszóismétlést („Password” és „Confirm password”). A „User must change password at next logon” jelölőnégyzet mellől vegye ki a pipát, ezzel kötelező jelszómódosítást követelne ki az SQL Server az első bejelentkezéskor! A „Default language” paraméternek válassza ki a „Hungarian”-t, így magyar nyelvi beállításokat rendelhetünk a felhasználóhoz. A bal oldali lapválasztóban kattintson a „Server Roles”-ra!

Kiadás: 2014.08.07.

Verzió: 3.10




A szerepkörök közül mindenképp válassza ki a „public”-t, illetve adhat „sysadmin” szerepkört a felhasználónak, ez esetben vigyázzon, mert a felhasználó minden SQL Server paraméter megváltoztatására jogot fog adni neki! A bal oldali lapválasztóban kattintson a „Status”-ra!

Kiadás: 2014.08.07.

Verzió: 3.10




Ellenőrizze, hogy a „Permissiton to connect to database engine” „Grant”-ra legyen állítva, illetve a „Login” „Enabled”-re. Ha kész, kattintson az „OK” gombra, ekkor az SQL Serveren létrejön a felhasználó. Ellenőrizzük, hogy a loginnal be tudunk-e lépni az adatbázis-kezelő rendszerbe.

2.1.2.2. Adatbázis létrehozása a Neptun3R tanulmányi rendszer adatai számára Amennyiben külön tárterületen (storage LUN-on, más meghajtón) lesznek elhelyezve az adatállományok, készítse elő használatra a tárt, hogy a Windowsban tallózható legyen! Éles adatbázist csak megbízható tárterületen (RAID-tömb, Storage LUN) helyezzen el, ügyelve arra, hogy I/O kapacitásban is megfeleljen a rendszer(ek) által támasztott elvárásoknak! Kattintson jobb gombbal a „Databases” csomópontra, a lenyíló lebegőmenüben válassza ki a „New Database” menüpontot!

Kiadás: 2014.08.07.

Verzió: 3.10




A következő lépésekben az adatbázis paramétereit mutatjuk be. Éles és teszt rendszerek esetén lehetnek eltérések a paraméterekben, ez külön jelezve lesz a dokumentációban.

A létrehozni kívánt adatbázisnak adjon egy egyedi nevet („Database name”), tanácsos, hogy a funkciójára utaljon a név (pl.: Neptun3r, Unipoll_teszt, stb…). Tulajdonosnak („Owner”) állítsa be

Kiadás: 2014.08.07.

Verzió: 3.10




a projekthez létrehozott felhasználót, az „Owner”-attribútum megadása mellett található „…” tallózógombbal nyissa meg a felhasználó-választó felületet!

A felhasználó kiválasztásához kattintson a „Browse” gombra!

A kinyíló tallózó ablakban válassza ki a projektfelhasználót, pipálja be a mellette található jelölőnégyzetet, majd az „OK” gomb megnyomásával lépjen tovább, bezáródik az ablak, majd az előző képernyőt kapja vissza.

A kiválasztás után az „OK” gomb megnyomásával léphet vissza az adatbázis létrehozásához. Ezután a „Database files” szekcióban vegyen fel állományokat, amit az adatbázishoz fog rendelni.

Kiadás: 2014.08.07.

Verzió: 3.10




Legalább 1 adat és 1 log állománynak lennie kell. Attribútumaik:  „Logical Name”: ez lesz a logikai neve az állományoknak, a rendszer automatikusan az adatbázis nevéből generálva ajánl fel nevet;  „File Type”: az adatbázis állományainak típusa: „Rows data”: adatállomány, „Log”: az SQL Server naplóállománya.;  „Filegroup”: alapértelmezetten létezik egy „Primary” állománycsoport, a naplók nem tartoznak állománycsoporthoz;  „Initial Size”: az állomány kezdeti mérete;  „Autogrowth”: a tárallokáció növekedésének üteme, %-ban vagy MB-ban kifejezve;  „Path”: az állomány helye, mely meghajtó, mely könyvtárában jöjjön létre;  „File Name”: a logikai névből generált fizikai állománynév. Az egyes attribútumok a cellába kattintás után változtathatóak meg. A kezdeti méret megadása a cellába kattintva írható be, a növekedés ütemének beállításához pedig a cella jobb oldalán található „…” gomb megnyomásával egy beállító ablakot nyit a telepítő.

Kiadás: 2014.08.07.

Verzió: 3.10




Itt engedélyezheti az automatikus allokációt az „Enable Autogrowth” jelölőnégyzet bepipálásával. Ezután a növekedési ütem alapja állítható be, hogy %-osan növelje a rendszer („In Percent” rádiógomb), vagy fixen megadott méretekkel („In Megabytes” rádiógomb). Mindkét választógomb mellett található egy beviteli mező, ahol az értékét is megadhatja. A

„Maximum

File

Size”

szekcióban

az

adatállomány maximális méretét korlátozhatja le „Restricted File Growth (MB)” jelölőnégyzet kiválasztásával,

illetve

a

konkrét

érték

megadásával, illetve kapcsolhatja ki a korlátozást „Unrestricted File Growth”, ez esetben az állomány a rendelkezésre álló szabad területet korlátlanul használhatja növekedésre. Az állományok helyének („Path”) megadásához a cella

jobb

oldalán

található

„…”

gomb

megnyomásával nyílik meg a tallózó ablak. A

tallózó

segítségével

adhatja

meg

az

adatállományok helyét. Ügyeljen arra, hogy a könyvtárra – amit itt kiválaszt – az MSSQL Servernek legyen írási joga. (A szerverpéldány telepítése során megadott „SQL Server Database Engine”-t futtató felhasználó.) Az „OK” gomb megnyomásával térhet vissza az adatbázis létrehozó felülethez.

Kiadás: 2014.08.07.

Verzió: 3.10




Ezzel az adatállományok és a tulajdonos kiválasztása megtörtént, lépjen tovább az adatbázis egyéb paramétereinek beállításához, a „Options” lapra váltva.

A karakter-egybevetésnek („Collation”) válassza ki a listából a „Hungarian_CI_AS” –t. (Magyar nyelvi, kis/nagybetű érzéketlen, ékezethelyes beállítás). A visszaállítási modellként („Recovery Model”) éles rendszer telepítése esetén a „Full”-t válassza, tesztrendszer létrehozásakor állítsa „Simple” modellre, „Compatibility level”-ként válassza az „SQL Server 2008”-t! (Kivéve, ha erről az adatbázisból a későbbiekben régebbi verziójú SQL Server-re szeretne másolatot készíteni, ez esetben viszont az SQL Server 2008 nyújtotta lehetőségeket nem fogja tudni használni!) Az „OK” gomb megnyomásával az SQL Server létrehozza az adatbázist, ez a létrehozni kívánt adatállományok méretének arányában több percig is eltarthat.

Kiadás: 2014.08.07.

Verzió: 3.10




Ezután a felhasználók-adatbázisok összerendelése következik. Válassza ki a létrehozott projektfelhasználót, kattintson rá jobb gombbal, és válassza ki a lebegőmenüből a „Properties” menüpontot!

Kiadás: 2014.08.07.

Verzió: 3.10




Váltson át a „User mapping” lapra, itt adhat jogosultságokat a felhasználónak az egyes adatbázisokra. A „Users mapped to this login” listában láthatja a felsorolva a példányon futó adatbázisokat, illetve a „Database role membership” listában a felhasználó, a fenn kiválasztott adatbázishoz tartozó szerepköreit.

Válassza ki a projektadatbázist, és ellenőrizze, hogy a felhasználó tulajdonosa-e („db_owner”) és publikus-e („public”). Együttműködő rendszerek esetén (pl.: Neptun-Unipoll, Neptun-Poszeidon) a másik projekthez tartozó felhasználónak olvasási joggal kell rendelkeznie erre az adatbázisra: legyen a „public” és a „db_datareader” szerepkör kiválasztva a mellette található jelölőnégyzet segítségével. Pl.: a Neptun usernek az Unipoll adatbázisára legyen olvasási joga, az Unipoll usernek a Neptun adatbázisára.) Az „OK” gomb megnyomásával az adatbázis-szintű szerepkörök, jogosultságok is összerendelésre kerültnek, használatba veheti az adatbázist.

Kiadás: 2014.08.07.

Verzió: 3.10




2.2. Alkalmazás szerver telepítése 2.2.1. Előfeltételek A Neptun.NET rendszer középréteg szervere más néven alkalmazás szerver a Microsoft .NET Framework keretrendszerre épül. A megfelelő operációs rendszer és frissítések telepítése után a kiszolgáló alkalmazások telepítése következik. Az operációs rendszerek különböző típusai és különböző kiadásai eltérő módon tartalmazzák a különböző .NET Framework verziókat. Ezt külön nem részletezném, csak a szükséges komponensek listáját részletezem. Értelemszerűen, ami nem kerül fel az operációs rendszer alap telepítése során, azt utólag kell telepíteni. Természetesen ügyelni kell az operációs rendszer és a .NET Framework komponens nyelvi egyezésére is. Bizonyos esetekben előfordul, hogy az adott komponensnek nincs magyar nyelvű verziója. Ez azért lehet, mert nincs nyelvi függőség az operációs rendszerrel. Ez az eset inkább csak javító csomagnál fordul elő. Szükséges .NET Framework verziók: 

Microsoft .NET Framework 4.5 (a 2014 nyári verziótól kezdve)

Miután feltelepítettük az operációs rendszer éppen elérhető összes frissítését és az összes szükséges .NET Framework verziót, át kell állítani az operációs rendszer területi és nyelvi beállításait. Erre azért van szükség, mert a Neptun3r rendszer bizonyos részei alkalmazkodnak az adott környezet területi beállításaihoz. Legszemléletesebb példa az órarend kezelése. Amennyiben az alkalmazás szerver területi és nyelvi beállítása angol vagy amerikai akkor a hét első napja vasárnap, és ez egy nap elcsúszást okozhat az órarendi megjelenítésben. Ugyanez magyar területen már nem így van, hiszen ott a hét első napja hétfő. Ezt a beállítást a „vezérlőpult” (Control Panel), „Területi és nyelvi beállítások” (Regional and language options) panelján tudjuk elvégezni. A helyes beállítások a következő ábrákon láthatók.

Kiadás: 2014.08.07.

Verzió: 3.10




Ezen nyelvi beállítást mindenképp az Oracle kliens telepítése előtt kell elvégezni. Ellenkező esetben a registry-ben hibás alapértelmezett karakter készlet kerül bejegyzésre. Mind a kétféle támogatott adatbázis kezelő szoftver (MSSQL, Oracle) igényli a középréteg szervereken a kliens alkalmazás meglétét. Míg Oracle estében kötelezően szükséges a kliens telepítése, az MSSQL esetén a jobb kapcsolati mutatók miatt erősen ajánlott a telepítés.

Kiadás: 2014.08.07.

Verzió: 3.10




2.2.1.1. Oracle kliens telepítése: A jelenleg támogatott Oracle verzió a 11.2.0.3. Az 11g kliens a telepítését mutatják az alábbi screenshotok. A telepítőkészlet az Oracle oldaláról letölthető és megfelelő licence szerződés esetén legálisan használható. Jelentkezzen be egy olyan felhasználóval, akinek lesz joga telepítéseket végrehajtani, könyvtárakat létrehozni, rendszerállományokat szerkeszteni. Windows alatt mindenképp Adminisztrátor jogú felhasználóval jelentkezzen be és indítsa el a telepítőcsomag gyökérkönyvtárában található „setup.exe” programot! Legelőször néhány ellenőrzést hajt végre a telepítő (pl.: támogatott szoftverkörnyezet, szabad hely), ha sikeresen lezajlott a művelet, az alább látható telepítőképernyő fogadja. Ha nem volt sikeres, értesíti Önt, hogy mi miatt nem folytatódhat a telepítés.

Első lépésben ki kell választanunk a telepítés típusát, itt a „Custom” („egyéni”) telepítést jelöljük ki, így tudja legjobban testre szabni a kliensprogramot, és csak a szükséges komponenseket kiválasztani a telepítés során. A „Következő”-re kattintva haladhat tovább.

Kiadás: 2014.08.07.

Verzió: 3.10




A rendszertelepítés első lépése a támogatott nyelv kiválasztása. Az angol („English”) nyelv kötelezően a kiválasztott nyelvek közé kerül, illetve, ha az operációs rendszerének területi beállításai az angoltól eltérnek – pl. magyar – a rendszer automatikusan azt a nyelvet is kiválasztja. Ha magyar beállításokkal szeretné telepíteni a rendszert, és nem ajánlotta fel automatikusan, ellenőrizze le az operációs rendszer területi beállításait! Ha további nyelvek támogatását is szeretné telepíteni, az „Available languages” („Elérhető nyelvek”) oszlop elemei közül, a nyelvet/nyelveket kijelölve a középen található nyilakkal helyezheti át a „Selected languages” („Kiválasztott nyelvek”) oszlopba. A nyelv(ek) kiválasztása után kattintson a „Következő” gombra!

Kiadás: 2014.08.07.

Verzió: 3.10




Az Oracle kliens könyvtárainak megadása következik. Egy „Oracle Base” és egy „Software Location” könyvtárat kell megadnunk. Ha ezek a könyvtárak még nem léteznek, a telepítő létrehozza őket. Az „Oracle Base” könyvtárban fogja a telepítő az Oracle környezetet felépíteni, az aktuálisan telepítendő kliensalkalmazás pedig a „Software Location” könyvtárba fog kerülni. A könyvtárak megadása után lépjen a tovább a „Következő” gombbal!

Kiadás: 2014.08.07.

Verzió: 3.10




A komponensek kiválasztása a klienstelepítés legfontosabb lépése. Mindenképp válassza ki az alábbi opciókat:  „Oracle Object for OLE”,  „Oracle Provider for OLE DB”,  „Oracle Data Provider for .NET”,  „Oracle Providers for ASP.NET” ,  „Oracle Net”. Rendszergazdák, DB adminisztrátorok számára hasznos segítség az alábbi 2 komponens:  „Oracle Database Utilities”: Oracle varázslók, hasznos eszközök;  „SQL*Plus”: parancssoros SQL felület; További komponensekre szüksége lehet még attól függően, milyen egyéb alkalmazást kíván használni: 

„Oracle Call Interface (OCI)”;

 „Oracle ODBC driver”.

Kiadás: 2014.08.07.

Verzió: 3.10




OCI és ODBC kapcsolatot akkor használjon, ha van olyan alkalmazása, ami ezeket igényli, pl.: PL/SQL dev, Toad, stb. Az egyes alkalmazások leírásában megtalálhatja, milyen kapcsolatot igényelnek. A kiválasztás után haladjon tovább, kattintson a „Következő”-re”!

A következő képernyőn egy folyamatkijelzőn követheti nyomon a telepítő által végzett ellenőrzések (hardver, szoftver, szabad terület, stb.) folyamatát, az teljesen automatizáltan zajlik, felhasználói beavatkozást nem igényel. Ha elkészült vele, aktívvá válik a „Következő” gomb, tovább léphet.

Kiadás: 2014.08.07.

Verzió: 3.10




A sikeres ellenőrzés után egy riportot generál, amit a „Save response file” gombra kattintva elmenthet. A riportban egy összefoglalót talál az eddigi beállításokról. A „Befejezés” gombra kattintva haladjon tovább!

Kiadás: 2014.08.07.

Verzió: 3.10




A kliens tényleges telepítését elvégzi a telepítő, ezen az oldalon is egy folyamatkijelző látható. Ha részletesebben szeretné látni a telepítés folyamatát, a „Details” gombra kattintva egy ablakban nyomon követheti, mely komponenseket telepítette fel eddig, és sikeres volt-e az egyes komponensek telepítése. Ha a folyamat végét elérte a telepítő, már csak a záró képernyőre vált át a telepítő.

Kiadás: 2014.08.07.

Verzió: 3.10




A záró képernyőn ideális esetben a „The installation of Oracle Client was successful.” üzenetnek kell megjelennie, ezzel kész az Oracle kliens telepítése. Ha a telepítés során hiba lépett fel, a pontos hibaüzenetet is itt fogja a telepítő megjeleníteni. 2.2.1.1.1. Nem managelt DataAccess A 426.4 előtti Neptun.NET verziókban 2 állománnyal kapcsolatosan van még teendője. Elsőként az Oracle.DataAccess.dll verziószámát kell megnéznie, feljegyeznie. Az állomány a telepítéskor megadott „Software Location” könyvtáron belül az „ODP.NET/BIN” alkönyvtárába lépjen be! (Régi Oracle 10g kliensekben a „BIN” alkönyvtárban található!) A „ODP.NET/BIN”-en belül alapértelmezetten található egy „2.x” alkönyvtár, ez a .NET Framework 2 alapú rendszerek providerének a helye (.NET 3.5-ig minden verzió csak egy kiterjesztés volt .NET 2.0-hoz). Ha újabb klienst telepítünk, vagy ODAC („Oracle DataAccess Component”) már létrejön egy „4” könyvtár is, mert a .NET Framework 4 már önálló keretrendszer.

Kiadás: 2014.08.07.

Verzió: 3.10




A „2.x” és a „4” könyvtár tartalmazza az Oracle.DataAccess.dll-t. Kattintson jobb gombbal az állományra, a lebegőmenüből válassza ki a „Properties” („Tulajdonságok”) menüpontot. A megnyíló ablakon váltson a „Details” („Részletek”) fülre. Egy tulajdonságlistát fog látni, a „Product version” („Termék verziószáma”) sorban olvasható a verziószám. Ezt jegyezze fel, a későbbiekben még szüksége lesz rá! A másik állomány, amire szüksége lesz, a „tnsnames.ora”,ez az Oracle névfeloldó file. Ennek a „Software Location” könyvtár „NETWORK\ADMIN” alkönyvtárában kell lennie, ha nem létezik, hozza létre, például „notepad” („jegyzettömb”) program segítségével. A tartalma szerkeszthető szöveges, adatbázis példányra mutató „alias”-t (akár több is lehet) kell definiálni benne az alábbi példa szerint: ADATBAZIS_ALIAS= (description= (address= (protocol = TCP) (host=SZERVER_NEVE_VAGY_CIME) (port=1521) ) (connect_data= (server = DEDICATED) (service_name=PELDANY_NEVE) ) )

A tnsnames.ora fileban az alábbi paramétereket szerkesszük meg:  ADATBAZIS_ALIAS: egy Ön által választott egyedi aliasnév, amivel a programokból hivatkozhatunk rá, pl.: „NEPTUN_ELES”;

Kiadás: 2014.08.07.

Verzió: 3.10




 PROTOCOL: a példányhoz tartozó listener által használt protokoll;  HOST: az adatbázis példányt futtató szerver neve, vagy címe;  PORT: a példányhoz tartozó listener portszáma;  SERVER: „shared” vagy „dedicated”, az adatbázispéldány típusa;  SERVICE_NAME: az adatbázis példány neve (SID-je). Ha több szerverre is szeretnénk hivatkozni, egymás alatt több ilyen blokkot is létrehozhatunk. Mivel a telepítés során nem kevés új bejegyzés keletkezett a registry-ben ajánlott egy teljes újraindítás. 2.2.1.1.2. Managelt DataAccess A 2014 nyári verziótól kezdődően a Neptun.NET rendszer ún. „managelt”, beépített Oracle DataAccess komponenssel rendelkezik, már nem az Oracle kliens Oracle.DataAccess állományát fogja használni. Az előző alfejezetben bemutatott „tnsnames.ora” állományt tartalmazó könyvtárra vegyünk fel egy globális rendszerváltozót a Windows-ban „TNS_ADMIN” névvel, értéke pedig ennek a könyvtárnak a teljes elérési útja szerepeljen:

A lépései: Vezérlőpult / Control Panel => Rendszer / System => Speciális Rendszerbeállítások / Advanced system settings link => Speciális / Advanced lapfül => Környezeti változók / Environment Variables gomb => Rendszerváltozók / System variables lista. Az Új / New gomb megnyomásával adhatja hozzá az új rendszer változót. Az OK gombokkal véglegesítheti a változást és zárhatja be az ablakokat.

Kiadás: 2014.08.07.

Verzió: 3.10




Lényeges, hogy miután minden telepítés megtörtént legyen kikapcsolva a Windows frissítések automatikus telepítése. Amennyiben szeretnénk, hogy a rendszer automatikusan keresse a frissítéseket, bekapcsolva lehet hagyni azt, de semmiképp ne legyen engedélyezve az automatikus telepítés. Ennek az a magyarázata, hogy ha bizonyos frissítések miatt a gép újraindul, és az például egy vizsgajelentkezési vagy tárgyfelvételi időszakban van, akkor jelentős elégedetlenséget válthat ki a szolgáltatás kiesése. Találkoztunk már olyan hibajelenséggel is, hogy a szerver újraindulása után előbb próbálja indítani a Neptun szervizt a Windows, mint hogy annak a működéshez szükséges összes feltétele biztosított lenne (pl. hálózati kapcsolat, adatbázis elérés, stb.). Ajánlott beállítás továbbá a központi időszinkronizálás. Amennyiben ez nem lehetséges akkor helyi üzemeltetési feladat a szerverek egységes időbeállítása. Komoly problémát tud okozni több web szerver használatánál, hogy az egyik már engedi a tárgyfelvételt (akár a meghirdetett időpont előtt is) a másik pedig még nem. A középréteg szerverek működésénél két szolgáltatás elérhetőségét kell beállítani az intézményi és a lokális tűzfalon. Ez a két szolgáltatás az SDA Informatika Zrt. központi szervere és az időbélyeg szervere. Mindkét szolgáltatást az SDA Informatika Zrt. a biztonság kedvéért redundánsan üzemelteti, azaz több telephely és több szerver van felkészítve a feladat ellátására. Annak érdekében, hogy ne kelljen az intézményi tűzfalat egy esetleges redundancia váltásnál állítgatni subdomain-hez kötöttük a szolgáltatásokat. Nevezetesen service1.sdakft.hu és service2.sdakft.hu ezen subdomain-ek felé kell megnyitni a tűzfalakon a 443 (ez a központi szerver) és a 8080 valamint a 8081 (ez az időbélyeg szerverek) portokkal való kommunikációt.

2.2.1.2. Az Oracle DataProvider regisztrálása, újraregisztrálása GAC-ba A Neptun.NET 426.3 verzióig az alkalmazás- és webszerverek az „Oracle.DataAccess.dll”-en keresztül tartják a kapcsolatot az adatbázissal. A DataProvider egy .NET-es függvénykönyvtár, amelyet a .NET Framework által használt assembly-gyorsítótárába (GAC = Global Assembly Cache) kell betölteni. Amennyiben az Oracle kliens telepítésekor már fel volt telepítve a .NET Framework, automatikusan beregisztrálja a DataProvidert. Ha a kliens előbb volt telepítve, vagy a .NET Frameworköt valamiért újra kell telepíteni, a DataProvider-t kézzel kell beregisztrálnunk a GAC-ba. Az Oracle kliens HOME-könyvtárán belül található az „ODP.NET\BIN\4” könyvtár, amelyben megtalálható az „Oracle.DataAccess.dll”, illetve az „OraProvCfg.exe”. Futtassa az alábbi parancsot (természetesen az Ön által használt elérési úttal:

Kiadás: 2014.08.07.

Verzió: 3.10




C:\Oracle\client\odp.net\bin\4\OraProvCfg.exe /action:gac /providerpath:Oracle.DataAccess.dll

2.2.2. Könyvtárszerkezet Amennyiben minden fent említett telepítés és beállítás megtörtént és a szükséges újraindítások is hiba nélkül lezajlottak, kezdhetjük a Neptun.NET könyvtár struktúra kialakítását. Ez a következő képen néz ki:  C:\Neptun.NET - ebben a könyvtárban fog elhelyezkedni minden, ami a Neptun3r rendszer működéséhez kell. Erre a könyvtárra legyen teljes írás olvasás joga a Rendszergazdák (Administrators) valamint a system csoportnak.  C:\Neptun.NET\Server - ebben a könyvtárban lesznek a szerver fájlok és könyvtárak. Ide soha ne kerüljön semmilyen nem a szerver működéséhez szükséges fájl vagy könyvtár és ne futassunk semmilyen más alkalmazást ebből a könyvtárból.  C:\Neptun.NET\Update - ebben a könyvtárban történnek azok a műveletek, amely a frissítéshez kapcsolódnak. A könyvtár struktúra kialakítása után megtörténhet a Neptun3r alkalmazás szerver állományainak bemásolása. Ez nem egy konstans állomány, hanem mindig egy adott adatbázis verzióhoz tartozóan változik. Az adott intézmény adott verziójú szerver állománya megtalálható az SDA Informatika Zrt. által üzemeltetett ftp szerveren. Ezen a szerveren minden intézménynek saját könyvtára van, amit csak az adott intézményi illetékes személyek és az SDA Informatika Zrt. jogosult személyei láthatnak. A

„server.zip”

csomag

tartalmazza

a

szerver

állományt.

Ezt

kell

kitömöríteni

a

„C:\Neptun.NET\Server” könyvtárba. A teljes állományt nem kívánjuk felsorolni mivel fent említett módon változó. Bizonyos fájlok mindig benne vannak a szerverbe, de ezek sem azonosak két különböző verzió tekintetében. Mindig kell, hogy legyen a szerver könyvtárban „SDAServerService.exe”. Ez az a file, amit a feltelepített Windows szerviz futatni fog.

2.2.3. Nevesített Windows Service telepítése Az SDA Informatika Zrt. által fejlesztett „SDAServerService.exe” telepíthető tetszőleges névvel.

Kiadás: 2014.08.07.

Verzió: 3.10




Erre azért volt szükség, mert bizonyos esetekben elképzelhető, hogy egy szerveren több Neptun szerviz kell fusson. Ilyen eset, pl. ha az adott szerveren nem csak egy intézmény Neptun szervere fut (host szolgáltatás), vagy az éles rendszer mellett teszt rendszer is van, aminek az alkalmazás szervere az éles szerver mellett kap helyet. A telepítés a megfelelő .NET Framework segítségével történik. A telepítés parancssorból történik: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe /desc="Neptun.NET application" /name="Neptun.NET" /disp="Neptun.NET" c:\Neptun.NET\Server\SDAServerService.exe

 /desc: Program leírása. Bármilyen rövid szöveg, ami segít beazonosítani az alkalmazást.  /name: Szerviz neve.  /disp: Megjelenítési név. Ez mindig legyen azonos a /name értékkel. Amennyiben 64-bites telepítést végez a Framework64\v4.0.30319\ könyvtárban található installutil.exe-t futtassa! Amennyiben sikerült feltelepíteni a Windows szervizt még be kell állítani néhány dolgot. Az indítás módját ildomos „Automatikus”-ra állítani.

Kiadás: 2014.08.07.

Verzió: 3.10




Lesz még szükség beállításra a FIR miatt, de azt majd ott részletezzük. Ld.:2.2.7.2.

2.2.4. Konfigurációs állományok beállítása Az alkalmazás szervernek a konfigurációs állománya a „ServerConfig.xml”. Ez egy szabályos xml file, de biztonsági okokból az SDA Informatika Zrt. által fejlesztett módon titkosítva van. Ezért nem lehet direktbe szerkeszteni. Minden módosítást az SDA Informatika Zrt. által fejlesztett „SDA.ConfigEditor.exe” program segítségével lehet elvégezni. A program lehetőséget ad minden olyan paraméter beállítására, ami intézmény specifikus. Ugyancsak ebben a programban kell szerkeszteni az elektronikus számlázáshoz szükséges paramétereket is. Ez a program is minden szerver csomagban benne van. Mint már fentebb említettük ez sem egyezik meg verzióról-verzióra. Ezért minden beállítást csak az adott szerverhez tartozó konfigurátorral lehet elvégezni. A program a „microsoft property grid” kontroll használatán alapul ezért jól kezelhetően mutatja az adott paraméter nevét, értékét és jelentésének leírását.

Kiadás: 2014.08.07.

Verzió: 3.10




Tekintve, hogy a szerver paraméterlistája is változó nem lenne célravezető, ha ebben a dokumentációban egyenként felsorolnánk a paramétereket névvel és leírással, hiszen ezek minden verzióhoz tartozóan megtalálhatók a programban. A program alkalmas arra is, hogy teljesen új „ServerConfig.xml”-t gyártson, ill. arra, hogy egy régi, de intézményi adatokkal feltöltött „ServerConfig.xml” file tartalmát áttöltse egy újabb „ServerConfig.xml” fájlba. Az új fájl létrehozása automatikus. Amennyiben nincs a mentés pillanatában „ServerConfig.xml” fájl a „SDA.ConfigEditor.exe” mellett akkor a program létrehozza azt a felületen beállított paraméterekkel. Az áttöltés igényel bemenő paramétereket.  Első paraméter: a forrás fájl neve teljes elérési úttal. Ez a fájl, ami az intézményi adatokat tartalmazza.  Második paraméter: a cél fájl neve teljes elérési úttal. Ez a referencia fájl. c:\Neptun.NET\Server\SDA.ConfigEditor.exe c:\Neptun.NET\ServerConfig.xml c:\Neptun.NET\Server\ServerConfig.xml

Ezt a program automatikusan is meg tudja csinálni, mert a „ServerConfig.xml” nem tartalmaz generált elemeket, tehát minden paraméter vagy ki van vezetve szerkeszthető módon, vagy a program tudja, hogy új elemként fel kell venni, illetve régi elemként törölni kell. Azaz, ha elindítjuk Kiadás: 2014.08.07.

Verzió: 3.10




a „SDA.ConfigEditor.exe”-t, az felolvassa az élő paramétereket, majd mentés után az új környezetbe illeszti azokat, így készítve egy aktuális „ServerConfig.xml”-t.

2.2.5. AD autentikáció Lehetőség van AD vagy LDAP autentikáció használatára a bejelentkezésnél, a rendszer képes akár több szerverrel is kapcsolatot tartani. Ezen szerverek szükséges paramétereit a SDA.ConfigEditor segítségével tudjuk elmenteni a konfigurációs állományba.

A megjelölt gombra kattintva egy gyűjteményszerkesztő nyílik meg, amiben a szükséges beállításokat el tudjuk végezni.

Kiadás: 2014.08.07.

Verzió: 3.10




Alapesetben teljesen üres a felület. Az „Add” gombra kattintva hozzáadódik egy új elem, amely ekkor már paraméterezhető. A szükséges beállítások: 

AdminPassword: A kapcsolódáshoz nem okvetlenül, de a felhasználói adatok módosításához kell.



AdminUserName: A kapcsolódáshoz nem okvetlenül, de a felhasználói adatok módosításához kell.



ADType: Jelenleg a rendszer MSActiveDirectory-t vagy eDirectory-t tud kezelni.



DefaultLDAPRootPath: Az alapértelmezett elérési útvonal megadása (ezen belül keresi közvetlenül az OU=Neptun Users csoportot).



LDAPHostName: Az LDAP vagy AD szerver IP címe vagy neve.



LDAPPort: Az LDAP vagy AD szerver kommunikációs port-ja.



NeedValidateCertificates: Ennek igazából jelenleg csak az LDAP-nál van értelme, szükséges-e tanúsítvány ellenőrzést végrehajtania vagy sem.



ModifySAMAccountNameOnLoginNameUpdate: tartományonként engedélyezhetjük, hogy Neptun-ban változó login név szinkronizálódjon-e AD-ba, (alapértelmezett érték: False).



ModifyUPNSuffixOnUpdate: Létező AD-s felhasználó módosításakor változzon-e a UserPrincipalName suffix is (alapértelmezett érték: True).



ActionType: tartományonként beállítható, két értéke lehet: OnlyAuthentication és FullSynchron. OnlyAuthentication értéknél csak a beléptetés lehetséges és a jelszóváltoztatás, FullSynchron esetén pedig új felhasználó és adatmódosítás is. Figyelem! Az alapértelmezett beállítás az OnlyAuthentication!

Természetesen az „Add” gomb újbóli lenyomása egy új elemet ad a listához, amit ugyancsak fel kell paraméterezni.

Kiadás: 2014.08.07.

Verzió: 3.10




Ha a listában kattintunk rá valamelyik sorra, akkor a paraméterei betöltődnek a szerkesztő felületbe és módosíthatóak vagy a kijelölt elem helye változtatható a prioritási sorrendben. Amikor a szerkesztő panelen az „Ok” gombra kattintunk, visszajutunk az SDA.ConfigEditorba, ahol immáron látszik a felvett két bejegyzés. Természetesen nem minden paramétere, mert az nagyban túlbonyolítaná a felületet. Csak a szerver neve vagy címe és az elérési útja látszódik. Az autentikáció jelenleg úgy történik, hogy sorrendben végigmegy az összes szerveren addig, amíg meg nem találja a hallgatót. Vagyis ha valamelyik szerver kiesik, az azon található felhasználók nem fognak tudni belépni. MS AD-ban, ha az üzemeltető megnyomja a hallgatók felületen az „AD szinkronizáció” gombot és be van állítva a szerveren az AD autentikáció, akkor az összes felhasználót létrehozza az elsőnek megadott szerverre, illetve ha létezik, akkor szinkronizálja az AD-ba. Ezek után mind az AD szinkronizáció gombnál, mind új felhasználó felvételekor az alábbi adatok vannak mentve:  „UserPrincipalName”-t és a „sAMAccountName”-t a bejelentkezési névre van állítva,  a jelszó formátuma: NeÉÉÉÉHHNN, ahol a ÉÉÉÉHHNN a születési évet, hónapot és napot jelenti. (ha a hónap vagy a nap egyszámjegyű, akkor 0-val egészíti ki) jelszó a születési dátum (pontok és szóköz nélkül) – mivel a Neptunban lehash-elt jelszót nem lehet visszafejteni,  a vezetéknév az „sn” attribútumban tároljuk,  a keresztnevet a „givenName” attribútumban,  a „displayName” attribútumban pedig a „teljes név (Neptunkód)” formátumban,

Kiadás: 2014.08.07.

Verzió: 3.10




 a „description” attribútumban tároljuk a Neptunkódot. Ha a fenti adatokban bármilyen változás van a Neptunban (név, bejelentkezési név, jelszó), akkor azok egyből bekerülnek az AD-ba is. Méghozzá a description-ben tárolt Neptunkód alapján megy az azonosítás, elvégre ez csak egyedileg kerülhet be a rendszerbe. Bár a config-ban benne van az SSL és a tanúsítvány ellenőrzésének lehetősége, ez egyelőre csak az LDAP-ra működik. Az AD szervereken alapértelmezetten az alábbi jelszó megadási szabály van megadva, amit a szinkronizálás miatt ki kell kapcsolni (mivel először a születési dátum a jelszó): If this policy is enabled, passwords must meet the following minimum requirements:  Not contain the user's account name or parts of the user's full name that exceed two consecutive characters  Be at least six characters in length  Contain characters from three of the following four categories:  English uppercase characters (A through Z)  English lowercase characters (a through z)  Base 10 digits (0 through 9)  Non-alphabetic characters (for example, !, $, #, %)  Complexity requirements are enforced when passwords are changed or created. Amennyiben az alapértelmezett, vagy az utólag megadott jelszó szabály nem engedi a nyolc csak számokból álló karakterláncot jelszónak használni, az AD szinkronizáció nem lesz sikeres. Ügyelni kell arra, hogy amennyiben használni kívánjuk az AD szinkronizációt, akkor az alkalmazásszerver Windows service futtató felhasználója admin jogkörrel bírjon az adott domainban. Erre azért van szükség, mert csak ebben az esetben fog tudni a Neptun módosításokat végezni az AD szerveren.

2.2.6. Alkalmazás szerver indítása Az alkalmazás szerver 391-es verziótól kötelezően elvárja az SDA root tanúsítvány meglétét az adott szerveren, mivel ettől a verziótól kezdve erre van szükség a központi szerverrel való kommunikációhoz. Kiadás: 2014.08.07.

Verzió: 3.10




Az SDA root tanúsítványának telepítése nem igényel semmilyen külön eljárást ezért nem készül róla külön fejezet. A gyökértanúsítványt is tartalmazó telepítő alkalmazás illetve a tanúsítvány tömörített formátumban letölthető több helyről is az SDA Informatika Zrt. szervereiről, illetve a termékportál nyitóoldaláról:  http://www.sdakft.hu/cert/SDARootCertificate.exe  http://www.sdakft.hu/cert/SDARootCertificate.zip  http://neptun.org.hu/ Amennyiben az exe-t töltjük le annak indításával azonnal települ a tanúsítvány, aminek eredményéről üzenetet kapunk.

Sikeres telepítés esetén:

Újra futtatás esetén: Windows 7, Windows Server 2008, Windows Server 2008 R2 operációs rendszerek esetében a Microsoft egy biztonsági fejlesztése miatt az internet Explorer futtatása, illetve gép újraindítás esetén az automatikus frissítés a Microsoft számára ismeretlen gyökér tanúsítványok törlésével járhat. Ez az SDA-s root tanúsítvány automatikus és kéretlen törlődését is jelenti. Sajnos mindezidáig egyetlen megoldást találtunk, a lenti screenshot alapján a ’Turn off Automatic Root Certificates Update’ értékét ’Enabled’-re kell állítani.

Kiadás: 2014.08.07.

Verzió: 3.10




Amennyiben minden eddigi lépés megfelelően végrehajtódott a Neptun3r szerver készen áll az indításra. Ez kétféle módon történhet: 1. kézzel a Windows szervíz indításával. 2. Windows utasítással. Itt értelemszerűen azt a nevet kell használni, amit a szerviz telepítésénél adtunk az alkalmazásnak: net start Neptun.NET

2.2.7. FIR beüzemelése Nem szerves része a Neptun3r szerver működésének, de a FIR rendszer működéséhez elengedhetetlenek a most következő telepítések és beállítások. A telepítés a szükséges file-ok beszerzésével indul.  IBMMQ7.exe Természetesen a szükséges file-okat az SDA Studio kft. mindenki rendelkezésre bocsátja az általa üzemeltetett ftp szerveren.  ftp://fir:[email protected]/SzerverInstall

Kiadás: 2014.08.07.

Verzió: 3.10




2.2.7.1. IBM MQ kliens telepítése Az IBM MQ kliensből most már csak a 7.5-öst lehet használni. Ez már 64 biten is képes működni. A telepítéshez szükséges file:  IBMMQ7.5.exe Abban az esetben, ha van régebbi verzió a gépen, mindenképp távolítsuk el, mielőtt elkezdenénk a 7.5-ös MQ telepítését. Az „uninstall” lépései a szokásosak: Vezérlőpult, Programok eltávolítása, IBM WebSphere MQ eltávolítás, next, next, finish. A régebbi verzió eltávolítása után mindenképp indítsuk újra a gépet! A telepítés ugyancsak teljesen egyértelmű, ezért nem szükséges lépésenként magyarázni mikor mit kell tenni, csak ellenőrizhetőség miatt a lépések képernyőit mellékeltük. Mindenhol a már beállított képernyő látható, tehát ha választani kell, akkor a kép szerinti beállítást kell elvégezni, mielőtt a tovább lépnénk. A telepítőkészletet önkitömörítő állományból indul, ami az „IBM MQ” könyvtárba tömöríti ki magát és el is indítja a „Windows\Setup.exe”-t.

Kiadás: 2014.08.07.

Verzió: 3.10



Kiadás: 2014.08.07.


Verzió: 3.10



Kiadás: 2014.08.07.


Verzió: 3.10




Telepítés után mindenképp indítsuk újra a gépet. Újraindítás után már csak a szolgáltatói tanúsítványok telepítését kell elvégezni.

Ezek után megint ajánlott egy szerver újraindítás. Ha ezek a telepítések sikeresen hiba nélkül lefutottak, akkor az IBM MQ telepítése rendben van.

2.2.7.2. A Neptun.NET Windows service futtató felhasználó beállítása A 405-ös verziótól a FIR funkcionalitás visszakerül a Neptun szerverbe. Mivel a FIR kommunikációhoz dedikált felhasználóra van szükség, ezért meg kell adni egy, az adott gép számára látható felhasználót, aki a NEptun. NET service-t futtatja. Nem elvárás hogy ez az SDA Informatika Zrt.-nek létrehozott felhasználó legyen. Lehet más helyi vagy Domain felhasználó is. A meglévő szolgáltatás futtató felhasználójának átállítása vagy ellenőrzése a szolgáltatás tulájdonságainál a legyegyszerűbb.

Kiadás: 2014.08.07.

Verzió: 3.10




A megnyíló panelen a „Log On” tabfülén lehet a futtató felhasználót és a hozzá tartozó jelszót beállítani.

Beállítás után a rendszer figyelmeztet, hogy a beállított felhasználó csak a szolgáltatás újraindítása után lép életbe.

Miután beállítottuk a felhasználót mindenképp be kell konfigurálni a megfelelő paramétereket a ServerConfig.xml-ben. Segítségünkre szolgál az SDA.ConfigEditor.

Kiadás: 2014.08.07.

Verzió: 3.10




Két paramétert feltétlenül állítson be! Az egyik a „testenvironment”, ennek az alapértelmezett értéke „True”, azaz tesztkulcsként akarja kezelni. Ezt éles rendszeren mindenképp állítsa „False”ra! A másik, az ütemezett automatikus ADLE–csomagtöltés időpontja. Ennek az alapértelmezett értéke 22:00, ha ettől eltérő időpontban szeretné futtatni, állítsa át!

2.2.7.3. A FIR kulcsok beállítása A FIR kulcsok, más szóval kapcsolódási paraméterek beszerzése az intézmény feladata a FI R-től. Ez egy záp file, ami általában az intézmény nevéből áll. Tartalma 5-6 file:  név.jks (keystore állomány)  név.kdb (kulcsadatbázis)  név.md5 (checksum)  név.sth (password stash file)  név.tab (csatornadefiníció)  _adatok.txt (ez a file tartalmazza a jelszót) Ezt az állományt el kell helyezni a C:\Neptun.NET\Server\Fir könyvtárban kitömörítve. (Elérési út értelemszerűen a Server alatt Fir könyvtár). Ez az állomány mellett kell elhelyezni a „SDA.FIR.Configurator.exe” programot. Ez egy az SDA Informatika Zrt. által fejlesztett segédprogram a kapcsolódási paraméter felhasználójának beállításához. Letölthető az SDA Informatika Zrt. szerveréről:  ftp://fir:[email protected]/SzerverInstall/SDA.FIR.Configurator.exe

A jelszó beírása után listázhatóak a kdb file-ban található felhasználók.

Kiadás: 2014.08.07.

Verzió: 3.10




A képen van egy fir, és egy kliens kulcs. A kliens azért kliens, mert ennek a felhasználónak a nevében lenne indítva az alkalmazás szerver, tehát a kapott programmal ezt át kell írni arra a felhasználóra, akinek a nevével az alkalmazásszervert futtatni akarjuk. A kliens nevűt kell átírni.

Kiadás: 2014.08.07.

Verzió: 3.10




Ezzel felkészítettük a fir kapcsolódási paramétereket a szerverrel való együttműködésre. Fontos tudnivaló, hogy a beállítandó felhasználónévben nem lehet „@” jel. Ennek ott van jelentősége ahol Domain felhasználót szeretnénk beállítani, mert az a Windows service futtató felhasználója. Sajnos az MQ kliens ilyen felhasználó névvel nem tud kapcsolódni, tehát a Neptun kliens kapcsolódási hibát fog dobni. Minden esetben csak olyan felhasználót lehet beállítani futtató felhasználónak, aki benne van a helyi felhasználók csoportban. Tekintve, hogy amennyiben a szerveren AD szerver funkcionalitás van telepítve, eltűnnek a helyi felhasználók és csoportok ki kell jelenteni, hogy ilyen szerveren nem fog működni a FIR feladás. Ezeket a kulcsokat nem szabad egyszerre az éles és a teszt szerveren használni, mert adatinkonzisztenciát okoz. (Az egyik szerver (adatbázis) által feladott üzenetre, a másik tölti le a választ, és az a másik adatbázisba kerül). Ezt csak egyszer kell elvégezni, utána hagyni kell az állományokat a szerveren. Miután mindent beállítottunk a paraméterek helyes beolvasása miatt állítsuk le a FIR és a Neptun Windows szervizt (ha futott) és indítsuk el. Először a Neptun-t majd a FIR-t. (Tesztelés: Delphi kliensből a 14100 számú felületen. Válasz lekérdezés gombja lekérdezi a válaszokat a FIR szerverről. Ennek értelmes válaszüzenetet kell kiírnia a képernyőre.) Tooltip: Ez a kis tool elég lassú, tehát minden gombnyomás kb. 10 másodperc, nem szabad megijedni tőle (MQ funkcionalitás ilyen).

Kommunikációs csatorna Ahhoz, hogy a kommunikáció működjön, az intézményi tűzfalon engedélyezni kell a Neptun.NET alkalmazás szerver és a FIR szerver között a 1444/tcp porton az adatforgalmat. Ennek meglétét telnettel tudjuk ellenőrizni. telnet fir2-live-frontend.fir.hu 1444

Amennyiben sikeres a kapcsolat egy üres konzol ablakot kapunk a bal felső sarokban villogó kurzorral.

Kiadás: 2014.08.07.

Verzió: 3.10




FirPut használata Ezzel az alkalmazással lehet letesztelni, hogy a FIR szervere képes e fogadni az intézménytől az adatokat. Szükséges file-ok:  FIRPut.exe  ibmwebspheremqfir.pem  OFIKMQ.dll Futtatást célszerű abból a könyvtárból elvégezni ahol a beállított kulcsok vannak és annak a felhasználónak a nevében, aki a kulcsokban be van állítva. Futatás történhet közvetlenül parancssorból, illetve batch file-ból. mindkét esetben a következő parancsot kell összeállítani. FIRPut.exe {system} {file} -t {tabfile} -s {system} -v -utf -m FIRELOTET.P

ahol:  {system} = a használó kulcs neve, ami a fileok neve, a kiterjesztés nélkül. Ha van a végén .t akkor a teszt szerverhez, ha nincs, az éleshez kapcsolódunk. pl.: kre vagy to2.kre.t  {file} = a file neve amit fel szeretnénk tölteni. Ha a firput.exe mellett van, nem kell elérési út. pl.: _adatok.txt  {tabfile} = a tabfile neve kiterjesztéssel együtt. pl.: kre.TAB Készült egy parancs fájlt (RunMe.cmd) ami egyszerűsíti a parancs összeállítását. Tartalma:

@ECHO OFF cls SET name= SET /P name=Parameter neve [tor.nep.t]? IF '%name%'=='' SET name=tor.nep.t IF NOT '%name%'=='' SET name=%name:~0,30% SET type= SET /P type=Ez teszt kulcs Y/[N]? IF '%type%'=='' SET type=P IF '%type%'=='N' SET type=P IF '%type%'=='n' SET type=P IF '%type%'=='Y' SET type=T IF '%type%'=='y' SET type=T

Kiadás: 2014.08.07.

Verzió: 3.10




ECHO Hasznalt parameter: %name% ECHO Kapcsolat tipus: FIRELOTET.%type% @ECHO ON FIRPut.exe %name% RunMe.cmd -t %name%.TAB -s %name% -v -utf -m FIRELOTET.%type%

Két információt kér be: 1. a használni kívánt kapcsolódási paraméter neve. pl.: kre

2. kapcsolat kiválasztása, hogy teszt vagy éles szerver kapcsolatot kell e vizsgálni.

Ha sikeresen lefut a küldés, akkor ezt látjuk az üzenetből.

Kiadás: 2014.08.07.

Verzió: 3.10




Ha nem sikeres a küldés, akkor három gond lehet.  nincs kapcsolat a szerverrel. Ezt telnettel tudjuk ellenőrizni,  hibásak a kapcsolódási paraméterek vagy nem fogad a FIR szerver,  nem az a felhasználó próbálja futatni a firput.exe-t, aki a kapcsolódási paraméterekbe be van állítva. A teljes FIRPut ellenőrző csomag elérhető az SDA Informatika Zrt. ftp szerverén.  ftp://fir:[email protected]/SzerverInstall/FIRput A fir kapcsolódási paraméterek beállítása után, - ha futott az Neptun3r alkalmazás szerver, - akkor újra kell indítani.

2.2.8. Alkalmazás szerver működése A Neptun alkalmazás szerver alapesetben megfelelő környezetben mindaddig fut és biztosítja a natív kliensek kapcsolódását, amíg leállításra nem kerül. Sajnos előfordulhat olyan eset, hogy akár hálózati kommunikációs, akár operációs rendszer probléma miatt megszakad a kapcsolat az adatbázis szerverrel. Ilyenkor az alkalmazás szerver leáll. Ezeket az úgynevezett végzetes hibákat az „SDAServerService.exe” több helyen is logolja. Minden a rendszerben keletkezett hibát (a „ServerConfig.xml”-ben beállított „loglevel” szintnek megfelelően) a szerver első körben az adatbázis log tábláiba próbálja menteni. Ha van adatbázis kapcsolat, akkor ez meg is történik. Abban az esetben, ha ez a loholás nem lehetséges, akkor az kritikus hibának minősül, és a szerver leáll. Ebben az esetben az alkalmazás szerver könyvtárában létrejön egy „LastWords” könyvtár, amelyben az alkalmazás szerver létrehoz egy „LW[dátum és idő].txt” nevű fájlt és beírja a kritikus hiba okát. Minden egyes hiba keletkezésekor új file jön létre. Ezzel párhuzamosan az „Event Log”-ban is keletkezik bejegyzés. Ilyenkor az alkalmazás egy saját „SDA” csoportba készít bejegyzést. Itt kell megemlíteni azt a fontos beállítást, hogy az „SDAServerService.exe”-t futtató Windows szerviz felhasználójának rendelkeznie kell az „Event log”-ba írási joggal. Amennyiben ez a jog nincs megadva a szerviz nem is indul el. Az indítási feltételek meglétének ellenőrzése céljából elindítható az „SDAServerService.exe” konzolos módban is. Semmiképp nem ajánlott így futtatni az alkalmazást, mert jelentősen veszít stabilitásából. C:\>”c:\Neptun.NET\Server\SDAServerService.exe” /console

Kiadás: 2014.08.07.

Verzió: 3.10




Lehetőség van a rövidebb kapcsolónév használatára is. A konzolos mód indítható „/c”, „/cd” vagy „/dc” kapcsolóval is. Tovább növelhető a kiírt információk mennyisége ha „debug” módban indítjuk a szervert. Ekkor kiírásra kerülnek a betöltött dll-ek, így ellenőrizhető mi nem biztosított az induláshoz. C:\>”c:\Neptun.NET\Server\SDAServerService.exe” /console

/debug

Lehetőség van a rövidebb kapcsolónév használatára is. A „debug” mód indítható „/d”, „/cd” vagy „/dc” kapcsolóval is.

SDA.DataProvider.dll használata Nagyon lényeges változás lép életbe a 402-es verziótól! Mivel egyre több intézmény használ 64 bites környezetet a jobb memória kihasználtság miatt és egyre szerteágazóbb az Oracle kliensek verziója egyre nehezebb kezelni a különbségeket. A Neptun tanulmányi rendszer az SDA.DataProvider.dll-en keresztül kezeli a különböző verziókat. A 402-es verziótól megszűnik az x64 és az x86 alkönyvtár. Azaz ettől a verziótól nem kell másolgatni az SDA.DataProvider.dll-t, mert csak egy van belőle. Ennek a kényelemnek sajnos ára van. Nem nagy, hiszen csak az első indulásnál kell átszerkeszteni a konfig állományokat. A módosítás lényege annyi, hogy a különböző DataAccess.dll verziószámát egységesíteni kell. Ezt egy un. „RunTime” bögben lehet megoldani. A Neptun alkalmazás szerver indító file-ja az SDAServerService.exe vagy a 64 bites környezetben az SDAServerService.x64.exe. Ezen file-ok mellett van egy-egy konfig állomány is. Név szerint az SDAServerService.exe.config és az SDAServerService.x64.exe.config file. Ezen file-ok közül értelem szerűen csak azt kell átszerkeszteni, amelyiket a rendszer használja. A módosítás annyi, hogy be kell szúrni a „ServerConfig” bög után a bekonfigurált „RunTime” bögöt. … <ServerConfig type="SDA.Framework.Remoting.Configuration.SDAServerSettings, SDA.Framework.Remoting"> … <dependentAssembly>
Kiadás: 2014.08.07.

Verzió: 3.10




publicKeyToken="89b483f429c47342" /> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>

Itt a verziószámnál kell megadni az adott gépen található Oracle.DataAccess.dll assembly verzióját.

Ezt a file-t alap telepítés szerint az Oracle kliens „BIN” könyvtárában találjuk. Amennyiben az ODP.NET külön csomagként lett telepítve, akkor ott keresendő a DLL. Miután ezt a módosítást elvégezzük a konfig állományon ügyeljünk rá, hogy ne íródjon felül a release során. A legegyszerűbb, ha a módosított konfig file-t felvesszük a Release.exe-be, mint kivétel file. Természetesen, ha újabb Oracle klienst vagy ODP.NET-et telepítünk a szervere akkor a konfig file-t is módosítani kell.

2.2.8.1. Alkalmazás szerver parancsai Az alkalmazás szerver futása közben (annak leállítása nélkül is) lehetőség van bizonyos utasítások kiadására

illetve

információk

kinyerésére

a

rendszerből.

Kétféle

módon

képes

az

„SDAServerService.exe” utasítások befogadására. Az első egy igen egyszerű metódus, amikor nincs szükség visszajelzésre csak utasítani akarjuk a Neptun szervert. Ebben az esetben létre kell hozni egy „command.txt” fájt az alkalmazás szerver

Kiadás: 2014.08.07.

Verzió: 3.10




könyvtárában „[meghajtó]:\Neptun.NET\Server”. Ebben a fájlban lehet megadni a parancsot (egyszerre egy utasítást). A file elmentése vagy odamásolását az „SDAServerService.exe” futásidőben szinte folyamatosan figyeli és feldolgozza. A sikeres feldolgozás esetén a fájl törlődik. Tehát, ha a „command.txt” nem tűnik el maximum 5 percen belül akkor az utasítás nem került feldolgozásra. Abban az esetben, ha a beírt utasítás nem értelmezhető (elgépelés vagy nem létező parancs esetén) a „command.txt” akkor is eltűnik. Vagyis az üzemeltető felelőssége, hogy megfelelő parancsot adjon a szervernek. A másik lényegesen kifinomultabb módszer a „SDA.ServerController.exe” (továbbiakban kontroller) használata. Ez az alkalmazás azért készült, hogy a szerviz módban futó Neptun szerverhez lehessen kapcsolódni. Ebben az esetben a kapcsolódástól a szerver által közölt üzenetek is láthatóak. Nem javasolt a folyamatos monitorozás, mert jelentős performancia veszteséget eredményez.

Ezt

megtámogatandó

bizonyos

idő

után

kilép

a

kontroller.

Az

SDA.ServerController.exe indításkor hitelesítést igényel, azt a felhasználónév-jelszó párost kell megadni, amivel az operációs rendszerben is hitelesítettük magunkat! A hitelesítés a rendszernapló-bejegyzések (Eventlog) miatt vált szükségessé. Előfordulhat, hogy a futtató felhasználónak nincs jogosultsága rendszernaplóba írni, ilyenkor „Futtatás rendszergazdaként” („Run as administrator”) módban indítsuk el az alkalmazást.

A kontroller indításához a „SDA.ServerController.exe” fájlt kell elindítani a szerver könyvtárból. Lényeges, hogy ebből a könyvtárból induljon, mert a kapcsolódáshoz szükséges információkat a „ServerConfig.xml”-ből veszi. Kapcsolat indításához a „Connect” gombra kell klikkelni. Ekkor a felirat átvált „Disconnect”-re. Idő túllépéskor történő szétkapcsolódáskor is „Connect” feliratra vált a gomb szövege. Szétkapcsolt állapotot abból is látjuk, hogy az üzenet ablak szövege elhalványodik. A kiadható parancsok listája a „help” parancs kiadásával megjelenik. Minden

Kiadás: 2014.08.07.

Verzió: 3.10




begépelt parancs csak a „Send” gombra kattintva vagy „enter” leütése után kerül elküldésre. Ez a gomb és a beviteli mező természetesen csak kapcsolódás után aktív. Néhány fontosabb parancs:  send [üzenet szövege] -> üzenetet lehet küldeni minden aktív kliensre,  updater reload -> újratölti a kliens frissítéskor használt fájlokat,  license reload -> újraolvassa a licensz fájl információit,  version -> kiírja az alkalmazás szerver és az adatbázis verzió számát,  info -> kiírja a kapcsolódási paramétereket, a szerver nevét, használt port számát, aktív kapcsolatok számát, stb,  server message [üzenet szövege] -> kliens hibajelzés területén megjeleníti az üzenet szövegét a parancs kiadása utáni kapcsolódó klienseknek, amikor a Neptun szerver áll, de az „SDAServerService” fut. Ez akkor lehet hasznos, ha le kell állítani a szervert dll csere miatt. Ekkor a kliensek nem a „Hálózati kommunikációs hiba” feliratot látjuk, hanem az üzenet szövegét.  server stop -> leállítja a Neptun szervert és elindít egy „fake” szervert. Ezzel egy időben kiüríti a szerver által használt dll-eket is a memóriából,  server start -> leállítja a „fake” szervert és elindítja a Neptun szervert.

2.2.8.2. Üzenetküldés beállításai és működése A Neptun.NET rendszerben háromféle üzenetküldésre van lehetőség:  Neptun.NET saját belső rendszerüzenetek,  Intézményi SMTP szervert használva email üzenet,  Mobil szolgáltatót használó SMS üzenetek. Mindhárom üzenetküldést a Neptun.NET alkalmazás szervere(i) vezérlik. Ebből adódik, hogy a szükséges beállításokat az alkalmazás szerverben lévő „SDA.ConfigEditor” végzi. Ezen beállítások a "Message sender options" részben találjuk meg.

Kiadás: 2014.08.07.

Verzió: 3.10




Az SMS szolgáltatás használatát a web szerveren is lehet szabályozni ezért a web szerver könyvtárban található „SDA.ConfigEditor”-ban is találunk egy "Message sender options" részt.

Az SMS küldés csak abban az esetben fog működni, ha az alkalmazás szerveren a „MessageProcessEnabled” paraméter „True”. Ennek az az oka, hogy az alkalmazás szerver dolgoz fel minden típusú (email, rendszer és sms) üzeneteket, de csak abban az esetben, ha el van indítva a job. Amennyiben engedélyezve van az SMS küldés, a szerver öt percenként ellenőrzi, hogy van-e elküldésre váró üzenet. Ha talál ilyet, elkezdi a feldolgozást. Az esetleges hibákat, ami a küldés során keletkeznek, logolja a rendszer.

Kiadás: 2014.08.07.

Verzió: 3.10




Az email küldést engedélyezni az „EmailEnabled” sorban lehet, de ez önmagában nem elegendő. Ki kell legyen töltve az „SMTP_Host” ugyanis, ez feltétele az email küldésnek. A belső rendszerüzenetek engedélyezése külön nem lehetséges. Ha a „MessageProcessEnabled” paraméter „True”, akkor van rendszerüzenet. Amennyiben több alkalmazás szerver működik, a küldési paramétereket következetesen minden szerveren ugyanúgy kell beállítani. Ennek az a jelentősége, hogy a szerver kezeli le az ütközési lehetőségeket és nem hagyja, hogy egymásra fussanak az üzenet feldolgozó folyamatok. Továbbá beépült egy olyan funkció is, ami a kiesett alkalmazás szerverektől átveszi az üzenetküldést. A feldolgozó folyamat a szerver (több esetén az első) indítása után öt perccel indul el és továbbiakban is öt percenként fut le. Amennyiben a feldolgozást végző alkalmazás szerver kiesik, de van másik, akkor öt perc elteltével átveszi a másik szerver a feldolgozást. Az email beállításánál figyelni kell arra, hogy az „SMTP_Host” (ami lehet IP cím vagy gép host név is) be legyen állítva. Ha ez nincs kitöltve vagy nem helyes, akkor az email küldések sikertelenek lesznek. Az SMTP szerver működésétől függően szükség lehet felhasználó azonosításra. Amennyiben nem engedélyezett a közvetlen kapcsolódás az SMTP szerverhez akkor szükséges kitölteni az „SMTP_user” és az „SMTP_password” paramétereket is. Ezen paramétereket általában az intézményi intranetet üzemeltető rendszergazda birtokában vannak. Amennyiben lehetséges a felhasználó azonosítása nélkül kapcsolódni az SMTP szerverhez akkor a fent említett két paraméter üresen hagyható. A kiküldésre szánt emailek ütemezésének céljából létrejött két új állítható paraméter a szerver konfigurációs állományában:  „emailsendingblockcount”: ezzel lehet beállítani, hogy egyszerre hány levelet olvasson fel és küldjön ki a rendszer. Ezek a levelek alkotnak egy „blokkot”.  „emailsendingtime”: ezzel a paraméterrel lehet szabályozni, hogy blokkok küldése között hány másodperc teljen el. Ezen fejlesztések által elkerülhető, hogy az azonos email szolgáltatónál lévő hallgatók nagyszámú levelét a szolgáltató spamként kezelje és így kiküldhető a nagyobb mennyiségű levél egyszerre, illetve a változtatható blokkméret és blokkok közötti várakozási idő segítségével az SMTP-szerver terhelését is egyenletesebben lehet elosztani – a Neptun alkalmazásszerver nem tudja túlterhelni a nagy mennyiségű levéllel.

Kiadás: 2014.08.07.

Verzió: 3.10




Nagyon fontos tudni, hogy az intézményi SMTP szerver hogyan van beállítva. Ugyanis kétféle email küldési beállítás van. Az első, hogy a SDA.ConfigEditor-ban beállított feladó, minden email feladója. Ebben az esetben csak azt kell biztosítani, hogy az intézményi SMTP szerver ismerje ezt a feladót és engedélyezve legyen az ő nevében az email küldés. A második eset, amikor az üzenet készítője az email feladója. Ebben az esetben csak akkor fognak elmenni az üzenetek, ha az intézményi SMTP szerver „open relay” módban fut. Ugyanis ebben az esetben az üzenet készítőjének az email címe lesz az email feladója. Amennyiben az SMTP szerveren nincs engedélyezve, hogy bármilyen (nem intézményi) email címről küldjön levelet, az alkalmazás szerver nem tudja kiküldeni az email-eket.

2.2.8.3. LMS telepítése 2.2.8.3.1. Fájlok másolása Első lépésben hozzon létre egy NeptunLMS mappát a szerveren, ezen belül pedig:  Contentroot/files mappa  Contentroot/zips mappa  ScormEngine.Web  LMSService

Kiadás: 2014.08.07.

Verzió: 3.10




2.2.8.3.2. Application pool létrehozása Hozzon létre Application Poolt az LMS számára: LMSAppPool, amely .Net 4.5 Framework-öt használ, „Integrated” felügyeleti módban!

2.2.8.3.3. Virtuális mappák létrehozása A virtuális mappák létrehozásához az alábbi műveleteket kell végrehajtania:  NeptunLMS -> Az 1. pontban létrehozott NeptunLMS fizikai mappára kell mutasson  NeptunLMS /LMSService -> LMSService fizikai mappára kell mutasson  NeptunLMS /ScormEngineInterface -> ScormEngine.Web fizikai mappára kell mutasson  Contentroot mappa -> Contentroot/files-re kell mutasson Mindegyik virtuális mappa application poolja az újonnan létrehozott LMSAppPool-t legyen!

2.2.8.3.4. Web.config beállítások ScormEngine.Web/scormenginesettings.config –ban az alábbi bejegyzéseket szerkessze meg: Az adatbázismotor típusa, egyelőre csak Oracle lehet:

SCORM db connectionstring-je.

Neptun db connectionstring-je.

A cormEngineInterface relatív url-je.

A tananyagból kilépve ide irányít át a rendszer. Alapértelmezetten bezárja a lejátszó ablakát.
Kiadás: 2014.08.07.

Verzió: 3.10




value="https://server.cime/NeptunLMS/ScormEngineInterface/exit.html" />

A ScormEngine.Web/web.config–ban az alábbi bejegyzéseket szerkessze meg: machineKey és autentikáció beállítása <machineKey decryption="Auto" decryptionKey="xxxxxx" validation="SHA1" validationKey="xxxxxx"/> …

A decryptionKey és a validationKey értékét egy machine key generátor segítségével lehet megadni. Autorizáció beállítása: <deny users="?"/>

A LMSService/web.config –ban az alábbi bejegyzéseket szerkessze meg: SCORM db connectionstring-je:

A létrehozott ScormEngineInterface url-je

Neptun DB connectionstring-je:

Az adatbázismotor típusa, egyelőre csak Oracle lehet:

A Contentroot mappa elérése:

A Contentroot/files mappa fizikai útvonala:

Kiadás: 2014.08.07.

Verzió: 3.10




A Contentroot/zips mappa fizikai útvonala:

Request szűrés beállítás: <system.webServer> … <security> <requestFiltering> <requestLimits maxAllowedContentLength="2097151001" />

A Neptun Web Hallgatói/Oktatói web.config szerkesztése: A létrehozott LMSService web szolgáltatás elérése. Fontos! A https tanusítványában szereplő domain, vagy ip cím alapján kell az url-t beállítani, különben nem fog menni a feltöltés

A scorm db connectionstringje:

MachineKey és autentikáció beállítása: <machineKey decryption="Auto" decryptionKey="xxxxxx" validation="SHA1" validationKey="xxxxxx"/>

Az autorizációs részt itt nem kell megadni, ez csak lms autentikációjához szükséges.

Kiadás: 2014.08.07.

Verzió: 3.10




2.2.8.4. LDAP szervizek telepítési dokumentációja 2.2.8.4.1. Szoftver követelmény 

A Webservice-ek IIS 7.x-esre telepíthetők.



A gépen a .Net Framework 4.5 kell, hogy telepítve legyen. ASP.NET tab fülön a .Net Framework 4.0-t kell beállítani, integrált felügyeleti móddal!

2.2.8.4.2. Beállítások IIS 7.x alatt 

Egy website alatt (lehet a default website is) jobb klikk és Add application (beállítani az Aliast,kiválasztani azt az Application pool-t ahol ASP.NET 4.0 van beállítva, és megadni az egyik könyvtár fizikai elérését) Az előbb leírt műveleteket, mindhárom könyvtárra el kell végezni!



A létrejött Application fülön be lehet állítani a Default Document menüben az .svc kiterjesztésű fájlt – kitörölve a default-ot.



Ha van server certificate beállítva az iis-ben, akkor ugyanezen a fülön van az SSL Settings, amiben be kell pipálni a „Require SSL”-t!

2.2.8.4.3. Web.config beállítások Mindegyik szerviz rendelkezik egy web.config fájllal, amelyben a szerviz beállításai vannak. 

A szervíznek látnia kell azt a gépet, ahol a NeptunServerService fut. Ennek a beállítása a

tagben van. 

Ahhoz, hogy a szervízhez csatlakozó kliensek ne csak üres xml-eket kapjanak, ezért vannak az LDAPStatuszok, LDAPSzemelyi könyvtárakban lévő web.config-ban a

taget kell beállítani. Az ott lévő IP címek (szigorúan csak IP címek) vesszővel elválasztva és space nélkül kerüljenek be! Ezek adják meg a csatlakozható klienseket. Persze a kliensek, ezen szervertől látható IP címüket kell megadni.

Kiadás: 2014.08.07.

Verzió: 3.10




2.2.8.4.4. Neptun DLL igények 

Ahhoz, hogy a szervíz konzisztensen működjön, a NeptunServerService által használt és a szervizek által használt LDAPTYPES.dll –eknek meg kell egyeznie.



A szervíz módosításánál a NeptunServerService mellett lévő PharosCommandLib.dll változhat a leggyakrabban így általában párhuzamosan az LDAPTYPES.dll el együtt cserélendő.



Természetesen a Neptun elég bonyolult ahhoz, hogy néha csak teljes verzió kihelyezése esetén lehet a szervizek működését garantálni, de az itt lévő első pontnak akkor is teljesülnie kell.

2.2.8.4.5. Szervizek aktualizálása A szervizek verzióra húzása esetén a dll-ek nem lépnek egyből érvénybe csak a következő esetekben: 

A dll–ek NeptunServerService mellé másolása után a szervízt újra kell indítani,



A web szervizek aktualizálásához egy iisresetet kell futtatni, vagy ha ez egyéb szolgáltatások futása miatt nem lehetséges a szerviz web.configjába lehet egy pl. space karaktert az xml tagek –en kívül rakni, és lementeni. Amitől az IIS úgy érzékeli, változott a szervíz és automatikusan újra indítja.

2.2.8.4.6. A szervizek szolgáltatásairól A szervizek a kiajánlott svc URL cím után írt „?wsdl „(GET paraméter) –el mutatják meg a wsdl ben a szervíz leírásaikat és az itt található xsd-hivatkozásokban az xsd-eiket. De SOAP kliens gyártható hozzá a megfelelő szoftverekkel (pl.: php, .net kliensek).

2.2.8.5. Filetárolók beállításai A Neptun rendszerben a dokumentumok egy része nem adatbázisban, hanem filetárolóban van kezelve. Ennek beállítása és karbantartása igényel némi odafigyelést. Elsőként a beállítás és használatba vétel feltételeit tisztázzuk. A tárolókat minden középréteg (tehát alkalmazás és web) szerveren azonosan kell beállítani. Ez azt jelenti, hogy ahány filetárolót használ

Kiadás: 2014.08.07.

Verzió: 3.10




a rendszer, az eléréseiket helyesen, minden szerveren be kell állítani. Amennyiben valamelyik szerveren nincs, vagy nem helyesen van beállítva valamelyik tároló elérése, akkor a teljes funkcionalitás leáll addig, amíg nem lesz teljes a tároló rendszer. Ennek a legfontosabb oka az, hogy rendeltetésszerű használat mellett több filetárolót kezel a rendszer. Amennyiben valamelyik tároló nem lenne elérhető, bizonyos dokumentumok nem lennének elérhetőek, ami félrevezető információ. Ezért inkább a teljes funkcionalitást leállítjuk, jelezve ezzel, hogy valamelyik filetároló elérhetetlenné vált. Beállításnál a szükséges paraméterek két helyen kerülnek letárolásra. Az egyik az adott középréteg szerver konfigurációs file-ban, a másik pedig az adatbázis. Sajnos ebben az esetben az üzemeltetőnek is szüksége van egy kis kliens használatra. Ebből a forrásból tudjuk kinyerni, hogy mi a filetárolók neve. Ez a kapcsolódási pont. A név az az azonosító, ami alkalmazás oldalról és üzleti logika oldalról közös. A kliensben az adminisztráció alatt a File tárolók az az 50650-es felületen találjuk.

Itt megtaláljuk a rendszer által ismert tárolók nevét, maximális méretét, titkosító kulcsát valamint prioritását. Ebből nekünk a név a fontos. A kisbetű/nagybetű különbözőnek számít! Etután a szervereken az SDA.ConfigEditor-al kell beállítanunk a további paramétereket.

Kiadás: 2014.08.07.

Verzió: 3.10




A „…” gombra kattintva előjön a beállítás panel.

Kiadás: 2014.08.07.

Verzió: 3.10




A beállítandó paraméterek magyarázata a fő panelen látható. Egy dolgot nagyon fontos tisztázni. Abban az esetben, ha egy adott filetároló más típusú elérésen van a különböző szervereken, akkor ügyelni kell az elérési útra és a típusra. Például ha az egyik szerver filetároló is egyben, akkor a rajta található szerveren a beállítás „Local”. Ezt a filetárolót értelemszerűen „Share”-nek kell beállítani a többi szerveren megfelelő felhasználóval és jelszóval (nem igaz ez akkor ha fel van csatolva a meghajtó). Bármilyen filetároló beállítás módosítása, csak a szolgáltatás újraindítása után lép életbe. A web-en ez az iisreset.

2.2.8.6. Neptun MeetStreet (közösségi tér) beállítása A Neptunban használható közösségi tér beállítása valójában egy filetároló hely beállításából áll. Kétféle elérés lehetséges, lokális filetároló, vagy távoli filetároló. Mindkét esetben lehetőség van autentikációra, ha szükséges. A konfigurációt az SDA.ConfigEditor-ban tudjuk elvégezni.

Kiadás: 2014.08.07.

Verzió: 3.10




 Maxfilesize: azt a file méretet határozza meg, aminél nagyobb file-t már nem enged kezelni a szerver. Ez csak a file méretére vonatkozó beállítás. Nem a filetároló méretét korlátozza, azt a kliensen kell beállítani, de ennek a méretnek logikai összefügésben kell lenni a filetároló maximális méretével. Az ábrán látható beállítás 50MB-nál nagyobb file-t nem kezel.  RepositoryName: a file tárolónevét definiálja. Ebben a verzióban csak egy tárolót lehet használni, ez azt jelenti, hogy minden szerveren ugyanazt a tárolónevet kell beállítani.  RepositoryPath: a file tároló elérési utja.

2.3. WEB alkalmazás 2.3.1. Könyvtár szerkezet Miután minden előtelepítés és beállítás megtörtént, és a szükséges újraindítások is hiba nélkül lezajlottak, kezdhetjük a Neptun.NET könyvtár struktúra kialakítását. Ez a következő képen néz ki:  C:\Neptun.NET - ebben a könyvtárban fog elhelyezkedni minden, ami a Neptun3r rendszer működéséhez kell. Erre a könyvtárra legyen teljes írás olvasás joga a Rendszergazdák (Administrators), valamint a system csoportnak.  C:\Neptun.NET\Web - ebben a könyvtárban lesznek a web szerver könyvtárak. Ide soha ne kerüljön semmilyen, nem a web szerver működéséhez szükséges fájl vagy könyvtár, és ne futassunk semmilyen más alkalmazást ebből a könyvtárból.  C:\Neptun.NET\Web\Oktatoi - ebben a könyvtárban lesznek az oktatói web működéséhez szükséges fájlok és könyvtárak.  C:\Neptun.NET\Web\Hallgatoi - ebben a könyvtárban lesznek a hallgatói web működéséhez szükséges fájlok és könyvtárak. Mind a hallgatói, mind az oktatói web alkalmazásból lehet több is egy szerveren. Ezt a 2.3.4-es fejezetben részletesebben is kitárgyaljuk, viszont a könyvtárstruktúra megtartása ajánlott. Ahhoz, hogy megfelelően működjenek a Neptun.NET webalkalmazásai (hallgatói- és oktatói web), a webet futtató felhasználónak el kell tudnia érnie a Neptun.NET webek állományait. Ehhez szükség van a hallgatói és oktatói web mappára és almappáira olvasási jogot adni a felhasználónak, valamint a „metabin” és a „pages/admin” mappára írási jogot is. Ezen felül egy könyvtárat ki kell jelölnünk a hibanaplók számára, az „ErrorLogPath” elérési útját az SDA.ConfigEditor programban lehet megadnunk. Amennyiben egy valós felhasználó – nem beépített rendszerfiók – nevében futtatja az

Kiadás: 2014.08.07.

Verzió: 3.10




IIS alkalmazáskészletet („application pool”-t), természetesen ennek a felhasználónak kell ezekkel a jogosultságokkal rendelkeznie. A könyvtár struktúra kialakítása után megtörténhet a Neptun3r webalkalmazás állományainak bemásolása. Ez nem egy konstans állomány, hanem mindig egy adott adatbázis verzióhoz tartozóan változik. Az adott intézmény adott verziójú web szerver állománya megtalálható az SDA Informatika Zrt. által üzemeltetett ftp szerveren. Ezen a szerveren minden intézménynek saját könyvtára van, amit csak az adott intézményi illetékes személyek és az SDA Informatika Zrt. jogosult személyei láthatnak. A

„web.zip”

csomag

tartalmazza

a

szerver

állományt.

Ezt

kell

kitömöríteni

a

„C:\Neptun.NET\Web\Hallgatoi” ill. a „C:\Neptun.NET\Web\Oktatoi” könyvtárba. A teljes állományt nem soroljuk fel, mivel fent említett módon változó. Bizonyos fájlok mindig benne vannak a szerverbe, de ezek sem azonosak két különböző verzió tekintetében.

2.3.2. Konfigurációs állományok beállítása A web szervernek a konfigurációs állománya a „web.config” fájl. Ez egy xml file, de biztonsági okokból az SDA Informatika Zrt. által fejlesztett módon titkosítva van egy része. Ezért nem lehet direktbe szerkeszteni. Minden módosítást az SDA Informatika Zrt. által fejlesztett „SDA.ConfigEditor.exe” program segítségével lehet elvégezni. A program lehetőséget ad minden olyan paraméter beállítására, ami intézmény specifikus. Ugyancsak ebben a programban kell szerkeszteni az elektronikus számlázáshoz szükséges paramétereket is. Ez a program is minden szerver csomagban benne van. Mint már fentebb említettem ez sem egyezik meg verzióról-verzióra. Ezért minden beállítást csak az adott szerverhez tartozó konfigurátorral lehet elvégezni. A program a „microsoft property grid” kontroll használatán alapul ezért jól kezelhetően mutatja az adott paraméter nevét, értékét és jelentésének leírását.

Kiadás: 2014.08.07.

Verzió: 3.10




Tekintve, hogy a web paraméterlistája is változó nem lenne célravezető, ha ebben a dokumentációban egyenként felsorolnánk a paramétereket névvel és leírással, hiszen ezek minden verzióhoz tartozóan megtalálhatók a programban. A program nem alkalmas arra, hogy egy teljesen új „web.config” fájlt gyártson. Ennek az az oka, hogy a „web.config” fájl tartalmaz generált elemeket is, amik a program fordításakor kerülnek bele. Viszont alkalmas arra, hogy egy régi, de intézményi adatokkal feltöltött „web.config” file tartalmát áttöltse egy újabb „web.config” fájlba. Minden web csomagban (web.zip) található egy „!Config” könyvtár, amely tartalmazza az aktuális programmal együtt fordított „web.config” fájlt. Ezt tekintjük referenciának. Az áttöltés igényel bemenő paramétereket.  Első paraméter: a forrás fájl neve teljes elérési úttal. Ez a fájl, ami az intézményi adatokat tartalmazza  Második paraméter: a cél fájl neve teljes elérési úttal. Ez a referencia fájl. c:\Neptun.NET\Server\SDA.ConfigEditor.exe c:\Neptun.NET\Web\Hallgatoi\web.config c:\Neptun.NET\Web\Hallgatoi\!Config\web.config

Kiadás: 2014.08.07.

Verzió: 3.10




2.3.3. Az IIS webkiszolgáló telepítése A Neptun3R rendszerben a web szerver is középréteg szervernek minősül. Az előtelepítés jellemzői, vagyis a támogatott operációs rendszerek, szükséges .NET Framework verziók, adatbázis kezelő kliens telepítése és a FastReport kliens telepítése megegyeznek az alkalmazás szerver telepítésénél leírtakkal. (2.2.1 fejezet). A fentieken kívül szükség van még a Microsoft IIS 7.x telepítésére is. Jelenleg a Neptun.NET rendszer nem támogat más web kiszolgáló alkalmazást. Az IIS 7.0 Windows komponens. Megtalálható minden Windows 2008 server és magasabb verziójú Microsoft operációs rendszerben. Telepítése nem történik meg az alapértelmezett telepítéssel, a már működő operációs rendszer alól telepíthető az alábbi módon. Első lépés az alap operációs rendszer telepítése után a frissítések feltelepítése. Ez egyszerű rendszergazdai feladat ezért ezt nem részletezném. Továbbiakban a „Server Manager” felületen kell elvégezni a szükséges telepítéseket és beállításokat.

Ahhoz, hogy legyen IIS és .NET Framework 3.5, telepíteni kell. Ez 2008-as szerveren „Add Roles” azaz „Szerepkör hozzáadás” menüpontban végezhetjük el.

Kiadás: 2014.08.07.

Verzió: 3.10




Ekkor egy varázsló indul el, amely végigvisz a teljes telepítésen. Első képernyő csak egy leírás. Kattintsunk a „Next” gombra.

A második képernyő már lényegesebb. Itt lehet bejelölni, hogy milyen „Role”-t, vagyis szerepkört szeretnénk telepíteni. Nekünk először az „Application Server” szerepkört kell kiválasztani.

Kiadás: 2014.08.07.

Verzió: 3.10




Ekkor azonnal megjelenik egy figyelmeztetés, hogy ez a szerepkör használatához elengedhetetlen a felsorolt komponensek telepítése. Kattintsunk az „Add Required Features” gombra, hiszen csak azért jelöltük be ez a szerepkör telepítését, hogy rávegyük a Windows-t, ugyan telepítse már fel a .NET Framework 3.5-ös verzióját SP1-el.

Ez után jelöljük be a „Web Server (IIS)” szerepkört.

Kiadás: 2014.08.07.

Verzió: 3.10




A következő képernyőn egy összefoglalót látunk a kijelölt „Application Server” szerepkörről és további konfigurációkat végezhetnénk el. Kattintsunk a „Next” gombra.

Egy újabb figyelmeztető ablakot kapunk, a szükséges komponensekről. Kattintsunk az „Add Required Features” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




Ekkor egy újabb választó ablakba érünk ahol a kiválasztott „Application Server” szerepkör egyéb telepíteni kívánt funkcióit állíthatjuk be.

A következő képernyőn egy összefoglalót látunk a kijelölt „Web Server (IIS)” szerepkörről. Kattintsunk a „Next” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




Ekkor egy újabb választó ablakba érünk ahol a kiválasztott „Web Server (IIS)” szerepkör egyéb telepíteni kívánt funkcióit állíthatjuk be. Alapból be van állítva minden lényeges összetevő, tehát kattintsunk a „Next” gombra.

Megtörtént a telepítés előkészítése. A varázsló összefoglalja mindazokat a szerepköröket és összetevőket, amit beállítottunk. A telepítés megkezdéséhez kattintsunk a „Next” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




A telepítés elindul.

Amint minden telepítésre került egy eredmény lista a záró ablak a varázslóban. Itt le tudjuk ellenőrizni, hogy minden telepítés rendben megtörtént e. Ha minden rendben van, kattintsunk a „Close” gombra.

Kiadás: 2014.08.07.

Verzió: 3.10




Ekkor visszajutunk a „Server Manager”-be. Ahol már kicsit élettel telibb a „Roles” felület. Indítsuk el az IIS-t. Kattintsunk a „Web Server (IIS)” linkre a „Roles Summary” szekcióban.

Itt tudjuk indítani és leállítani az IIS-hez tartozó szervizeket.

Kiadás: 2014.08.07.

Verzió: 3.10




Lépjünk be az „IIS Manager”-be. Most jönnek az IIS beállítás feladatai. Mindenek előtt, a tanúsítványt telepítsük és konfiguráljuk be. Lépjünk az IIS szerverünk gyökerébe. Itt találjuk a szerverre vonatkozó beállításokat. Duplán klikkeljünk a „Server Certification” menüpontra.

Kiadás: 2014.08.07.

Verzió: 3.10




Ekkor a szerver számára használható tanúsítványok tárát látjuk. Telepítsük fel az intézmény rendelkezésére álló tanúsítványt. Amennyiben file áll rendelkezésünkre kattintsunk az „Import…” eseményre. Ezzel egy egyszerű panel jelenik meg ahol a tanúsítvány file és az ahhoz tartozó jelszót kell megadni.

„OK” gombra kattintva a tanúsítvány bekerül a megfelelő tárba. Ha kivesszük a pipát a tanúsítvány exportálhatóként megjelölése elől akkor nem tudja tárolók között mozgatni a tanúsítványt a Windows. Sajnos erre szükségünk van, mert a későbbiek során gondot okozna, tehát hagyjuk bepipálva.

Ezután lépjünk a „Default Web Site”-ra ahhoz, hogy a tanúsítványt hozzá tudjuk rendelni. Kattintsunk a „Bindings…” eseményre.

Kiadás: 2014.08.07.

Verzió: 3.10




Megjelenik a felület ahol a szerver által használt portok konfigurálhatóak. Alapesetben csak a 80-as port van használatban. Nekünk a 443-as portot hozzá kell rendelnünk. Kattintsunk az „Add…” gombra.

Válaszuk ki a „https” típust a 443-as portot és a használni kívánt tanúsítványt. Itt van jelentősége a telepített tanúsítvány exportálhatóságának. Amennyiben nem vettük ki a pipát a jelölő négyzetből akkor itt hiba nélkül sikerülni fog a hozzárendelés.

Kiadás: 2014.08.07.

Verzió: 3.10




Véget ért az előkészítés. Hozzuk létre az alkalmazásokat. Eddig „virtual directory”-kat kellett létrehozni itt viszont „Application”-öket, azaz alkalmazásokat.

Írjuk be az alkalmazás hivatkozási nevét és a könyvtár elérési útját. Itt lehet beállítani az „application pool” használatát is.

Állítsuk be az alapértelmezett oldalt. Ezt a web site-on állva a „Default Document” menüpontban lehet megtenni.

Kiadás: 2014.08.07.

Verzió: 3.10




A Neptun web szerver indulásához a „main.aspx” oldalt kell beállítani. A web szerverek működésénél két szolgáltatás elérhetőségét kell beállítani az intézményi és a lokális tűzfalon. Ez a két szolgáltatás az SDA Informatika Zrt. központi szervere és az időbélyeg szervere. Mindkét szolgáltatást az SDA Informatika Zrt. a biztonság kedvéért redundánsan üzemelteti, azaz több telephely és több szerver van felkészítve a feladat ellátására. Annak érdekében, hogy ne kelljen az intézményi tűzfalat egy esetleges redundancia váltásnál állítgatni subdomainhez kötöttük a szolgáltatásokat. Nevezetesen service1.sdakft.hu és service2.sdakft.hu ezen subdomainek felé kell megnyitni a tűzfalakon a 443 (ez a központi szerver) és a 8080 valamint a 8081 (ez az időbélyeg szerverek) portokkal való kommunikációt.

2.3.3.1. .NET Framework regisztrálása-újraregisztrálása IIS alá Amennyiben a .NET Framework nem volt feltelepítve az IIS előtt, vagy újra lett telepítve, a .NET Frameworköt be kell regisztrálni az IIS webkiszolgáló alá, a feladat a .NET Framework 4 könyvtárából az „aspnet_regiis.exe”-t kell -i „install” kapcsolóval indítani. 32 bites rendszer esetén: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i

64 bites rendszer esetén: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i

Kiadás: 2014.08.07.

Verzió: 3.10




2.3.4. Web rendszer-adminisztrációs felület Az intézményi kéréseknek megfelelően a rendszerüzemeltetők számára készítettünk egy webes rendszer-adminisztrációs felületet, amely segítségével futásidőben állíthatják be és kérdezhetik le a hallgatói és oktatói webalkalmazások bizonyos paramétereit. A konfigurációszerkesztő program („SDA.ConfigEditor.exe”) segítségével beállított paraméterek csak a webalkalmazás indításakor kerülnek felolvasásra. A kiadott webes adminisztrációs felület segítségével ezen paraméterek, a szerver újraindítása nélkül is felülbírálhatók. A web rendszer-adminisztrációs felülete a webalkalmazás gyökérkönyvtárában található „admin.aspx” meghívásával jeleníthető meg, de biztonsági okokból csak és kizárólag localhost (127.0.0.1-es IP cím) felől szólítható meg, illetve az SDA.Configeditor-ban megadható „AdminPageIPs” alatt felsorolt címekről, vagy subnetekből. Ez esetben a megadási forma pl.: 192.168.1.0/24. (Ha konkrét cím van megadva subnet nélkül, az automatikusan „/32”-nek számít!) Minden más IP címről hívva az alábbi hibaüzenetet látható: „Nincs megfelelő jogosultság!”. Az adminisztrációs felület így csak a webkiszolgáló konzolára vagy távoli asztalára feljelentkezve egy böngésző segítségével nyithatja meg az adminisztrációs oldalt. Az IIS-ben ellenőrizze, hogy a webalkalmazásokat tartalmazó webhelyhez hozzá legyen rendelve a kötések között („bindings”) a localhost cím, ha nem minden „ki nem osztott címen” („all unassigned”) szolgál ki a webhely! Nyisson

egy

böngészőt,

navigáljon

a

webalkalmazás

admin.aspx

oldalára,

pl.:

https://localhost/hallgato/admin.aspx vagy az engedélyezett adminisztrátori gépekről a szokásos teljes URL-es formában meghívva: https://neptunwebszerver.intezmeny.hu/hallgato/admin.aspx.

Kiadás: 2014.08.07.

Verzió: 3.10




Amennyiben egy felületről szeretne több Neptun webalkalmazást is vezérelni, ez esetben egy kézzel szerkeszthető xml állományban több webalkalmazás url-jét is fel tudja sorolni egy-egy új „<webserver>” bög felvételével. Ezt az xml-t minden Neptun webalkalmazás könyvtárán belül itt találhatja: „/pages/Admin/WebServers.xml”. <webservers> <webserver name="Egyik web" url="http://localhost:23672/Web 3.5"> <webserver name="Masik web" url="http://localhost:23672/Web 3.5">

Ahhoz, hogy ne csak az adott webalkalmazáson, hanem mindegyik, az xml-ben felsorolt webalkalmazásra életbe lépjenek a változások, a változások jóváhagyásához majd ne a „Módosít”, hanem a „Módosít az összes szerverre” gombot használja – amelyik paraméternél van külön ilyen gomb! Az első lapfül az „Alapadatok”. Itt láthatja a szerver (konfigurációs paraméterekben beállított) nevét, illetve az aktuális licensz-információkat, illetve a bejelentkezett felhasználók számát (az aktív felhasználói munkamenetek alapján). A „Maximum User Szám” és a „Session Timeout Kiadás: 2014.08.07.

Verzió: 3.10




(perc)” kezdeti értékei a konfiguráció-szerkesztőben beállított értékek, ha még a webalkalmazás indítása óta nem lettek felülbírálva. A „Maximum User Szám” az egy időben bejelentkezett maximális felhasználói munkamenetek számát jelenti, a „Session Timeout” pedig azt, hogy egy felhasználói munkamenet maximálisan hány percig lehet aktív – ezen idő letelte után a munkamenetet a rendszer automatikusan megszünteti, ezzel megakadályozva, hogy felhasználók fölöslegesen foglalják a rendszer erőforrásait. „Hallgatónként megengedett egyidejű bejelentkezések száma” paraméterrel engedélyezhet több, egyidejű belépést a webalkalmazásba. 0 érték esetén korlátlan. A

„Neptun-debug”

jelölőnégyzettel

a

hibakeresési

információk

megjelenítése/elrejtése

engedélyezhető, az adatbázisban keletkező rendszerlogokat nem befolyásolja. A „Lapozás gyorsítótárazása” jelölőnégyzettel a webalkalmazásban szereplő gridek találatainak számát gyorsítótárazza a rendszer, ennek kikapcsolásával ez a funkció letiltódik, a grid minden újratöltésével adatbázisból újra fogja olvasni a rekordokat a webalkalmazás. A cache 5 percenként törlődik. Alapértelmezetten: True. A „DB terhelés optimalizálása” jelölőnégyzet segítségével minden felületen csak annyi rekord kerül az adatbázisból lekérdezésre, amennyire szükség van. Amennyiben kikapcsolja, mindig az összes rekord lekérdeződik, amelyekre nincs szükség, eldobódnak. Ez így jelentősen megnöveli az adatbázis terhelését! Alapértelmezett értéke: True! A „Maximális próbálkozások száma” paraméter segítségével megadható, hogy egy böngészőmunkamenet alatt hányszor próbálkozhat bejelentkezni a felhasználó sikertelenül. Ha elérte a paraméterben beállított értéket a sikertelen login-kísérletek száma, új böngésző-munkamenetet kell indítania (böngésző bezárás + újranyitás), így pl.: az automata-bejelentkeztető scriptes bejelentkezési próbálkozások ellen védhető a rendszer. Alapértelmezett értéke 30, ez esetben az 30 sikertelen próbálkozás után új böngésző-munkamenetet kell indítania a felhasználónak. Az „Online user” engedélyezése jelölőnégyzet segítségével engedélyezheti a belépett felhasználók online-ként való kijelzését a NeptunMeetStreet-ben a tagoknál. A „Login” gomb megnyomásával a webalkalmazás belépő képernyőjére lehet ugrani. A „Jogosultságok frissítése” és a „Cache ürítés” gombokat akkor kell használni, ha valamilyen szerepkör, vagy kritikus-táblát érintő kézi adatbázis-módosítás történt. Ezek hatására a rendszer a kritikus-táblákat újraolvassa.

Kiadás: 2014.08.07.

Verzió: 3.10




A „Session statisztika” fül alatt megtekinthető – ütemezett mintavételek alapján – az egyes webalkalmazások munkamenet-statisztikája, aktuális időpillanatokban hány aktív felhasználói munkamenet élt. A mintavételezési idők a konfigurációszerkesztőben a „SessionStatisticsMinute” megadott paraméter értékében állíthatók. A lap felső részén található dátumszűrő segítségével az ott beállított időintervallumra szűri a találatokat. A lista nyomtatható, illetve Excel táblázatként exportálható.

A „Felhasználói belépések” fül alatt megtekinthetők a jelenleg aktív felhasználói munkamenetek, részletezve a felhasználónevét, loginnevét, távoli IP címét, az aktív munkameneteinek számát. A „Csak a többször belépett hallgatók” jelölőnégyzet segítségével a lista szűkíthető azokra, akik több

Kiadás: 2014.08.07.

Verzió: 3.10




munkamenetben is be vannak jelentkezve. A munkamenetek törlésére („kilövésére”) is lehetőség van a felületen.

A

„Webszerverek”

lapfül

alatt

veheti

fel

azon

webalkalmazásokat,

amelyekre

csoportosan”állíthatja a felhasználószámot és a timeout-ot. Az „új szerver” gomb megnyomásával adhat hozzá újabb webalkalmazásokat a listához, a lehetőségek link alatt pedig törölheti, vagy módosíthatja ezeket a bejegyzéseket.

A „Kivételek” lapfülön az esetleges webalkalmazás-hibák eseménynapló-bejegyzéseit tekintheti meg, hibakereséshez hasznos információkat nyerhet ki belőle, pl.: a hiba megnevezését, a hibát okozó kivétel helyét is kiolvashatja a stacktrace-ből. Esetleges hiba esetén a fejlesztő így könnyebben tudja beazonosítani a hiba forrását.

Kiadás: 2014.08.07.

Verzió: 3.10




A „Kivétel fájlok” lapfül alatt pedig egy listát kap az ún. „LastWords” állományokról. A webalkalmazás leállását okozó események bekövetkezésekor a webalkalmazás a leállás előtt egy „LastWord” állományt hoz létre – ennek feltétele, hogy a webalkalmazás futtató felhasználója rendelkezzen írási joggal a hallgatói- és oktatói webek könyvtára alatt egy „LastWords” almappára. Az állományok nevének formátuma utal a keletkezés időpontjára: LWééééhhnnóóppss (éééé: év – 4 számjegyen; hh: hónap; nn: nap; óó: óra; pp: perc; ss: másodperc – 2-2 számjegyen). A „LastWords” állományok tartalma még részletesebb, mint a kivételek stacktrace-ének tartalma.

2.3.5. AD Autentikáció A web alkalmazásnál is lehet használni az AD vagy LDAP autentikációt. Beállítása és használata megegyezik a 2.6. pontban leírtakkal.

2.3.6. Web szerver indítási feltételek A 391-es verziótól a web szerveren is fel kell telepíteni az SDA root tanúsítványát. Ettől a verziótól a web szerveren is van Neptun license file. Ez a license file nem tér el az eddig is használt fájltól, ami az alkalmazás szerveren van. A license fájlt a web szerver gyökér könyvtárába kell elhelyezni a hallgatói és az oktatói webnél egyaránt. Amennyiben a license file nincs a könyvtárban, nem lesz elérhető néhány szolgáltatás, pl.: kollaborációs tér, timer. A frissítésnél nincs változás mivel a Release.exe alapértelmezett kivételként kezeli az „.n3l” kiterjesztésű fájlokat. Kiadás: 2014.08.07.

Verzió: 3.10




Ugyancsak a 391-es verziótól a web szerver könyvtár tartalma ellenőrizve van. Erre szolgál a „neptunwebhash.xml” fájl a gyökér könyvtárban. Ez azt jelenti, hogy a web szerver csak akkor fog elindulni, ha a könyvtárban annyi és azok a fájlok vannak, amik kellenek. Abban az esetben, ha kevesebb, több vagy nem oda illő fájl kerül a könyvtárba, a web szerver nem indul el. Az alábbi hibaüzenetek jelzik az egyes eltéréseket: 1. Hibás a „neptunwebhash.xml” fájl, mert kézzel módosítva lett.

2. Idegen fájl került a könyvtárba

3. Nincs meg a „neptunwebhash.xml” fájl.

4. Van olyan fájl ami nem azonos a hash-ben lévővel vagyis verzió eltérés van.

Kiadás: 2014.08.07.

Verzió: 3.10




Ennek a funkciónak a legnagyobb jelentősége a „patch” kihelyezésekor jelentkezik. Azt, hogy az éppen elindult verzió normál vagy „patch”-elt e, egy plusz információ jelzi a login képernyőn.

Formátuma: P és a „build”-elés dátuma. A 394-es verziótól a Neptun web szerverek csak abban az esetben indulnak el, ha be van kapcsolva az IIS-ben az SSL csatornatitkosítás!

Meta dinamikus dll-ek fordítása A Neptun tanulmányi rendszer működése közben dinamikusan dll-eket generál a meta lekérdezésekhez. Ezen fájlok helye a web szerverben a metabin/MetaAssemblies könyvtárban van. Előfordulhat, hogy a Windows nem engedélyez kellő jogosultságot ezen művelet elvégzéséhez. Ennek érdekében kézzel be kell állítani, hogy erre a könyvtárra (de inkább az egész web szerverre) írás/olvasás joga legyen a „Network Service” felhasználónak, illetve az ApplicationPool futtató felhasználójának.

SDA.DataProvider.dll használata Nagyon lényeges változás lép életbe a 402-es verziótól! Az SDA.DataProvider.dll-re vonatkozó változások a web szervert is érintik. Ezen pontban csak a web szerveren szükséges beállításokat írom le a magyarázat megegyezik a 2.2.8-as fejezet aznos fejlécű bekezdésében leírtakkal. A web szervernél sajnos a web.config file-ba kell beszúrni a szükséges „runtime” bögöt. Ez elég veszélyes, de kezelhető. Az alap probléma az, hogy minden release alkalmával cserélni kell a web.config file-t. Abban az esetben, ha ez a csere az SDA.ConfigEditor-al történik, semmi gond nincs,ugyanis az editor figyel erre a bög-re. Abban az esetben, ha nincs a régi konfigban beleteszi

Kiadás: 2014.08.07.

Verzió: 3.10




az alapot, amiben csak a verzió számot kell kijavítani. Ha van már ilyen bög, akkor békén hagyja és marad az álltatunk beállított verzió. Nagyon fontos, hogy ha kézzel tesszük bele a bög-öt akkor ügyeljünk rá, hogy nem lehet előrébb, mint a „configSections” bög. <section name="ServerConfig" type="ConfigsectionHandler"> <dependentAssembly>

Kiadás: 2014.08.07.

Verzió: 3.10




2.3.7. Terheléselosztás Abban az esetben, ha létrehoztunk több hallgatói oldalt, biztosítanunk kell, hogy a hallgatók mindegyiket el is tudják érni. Szempont továbbá az is, hogy mindegyik oldal közel azonos terhelést kapjon. Ennek több módja is van. Az egyik, ha az intézmény web oldalán elhelyezett link nem közvetlenül az egyik hallgatói web oldalra mutat, hanem egy terheléselosztó scriptre. Így a hallgatónak nem kell válogatnia a web címek között, hogy éppen melyiken van még lehetőség belépésre, hanem a script közel optimálisan elosztja a kéréseket. Példa script: <SCRIPT LANGUAGE="JavaScript"> function go_to(url) { window.location=url; } function rand_link_hallg() { var a; a = Math.round(Math.random()*5); // a = random számok 0-5 if (a==0) go_to("http://gépnév/hallgato"); if (a==1) go_to("http://gépnév/hallgato_1"); if (a==2) go_to("http://gépnév/hallgato_2"); if (a==3) go_to("http://gépnév/hallgato_3"); if (a==4) go_to("http://gépnév/hallgato_4"); if (a==5) go_to("http://gépnév/hallgato_5"); } function rand_link_okt() { var a; a = Math.round(Math.random()); // a = random számok 0-1 if (a==0) go_to("http://(IP vagy név)/oktato"); if (a==1) go_to("http://(IP vagy név)/oktato_1"); }

Nagyon fontos! Abban az esetben, ha új web szerver kerül elindításra vagy a meglévő web szerveren a „max session” számot növelünk, minden esetben követni kell az Oracle beállításokkal. A másik mód terheléselosztó rendszer alkalmazása. Többféle hardveres és szoftveres megoldás létezik a célra. Ennek konfigurálása és üzemeltetése minden esetben az intézmény feladata, és felelőssége. A neptun webhez tartozó erőforrás fájlok külső eszközön való gyorsító-tárazását csak abban az esetben szabad alkalmazni, ha új verzió kifrissítése során ezen gyorsítótár állományait is frissíti. Az SDA Informatika Zrt. által biztosított verziófrissítő eszköz ezt a frissítést nem végzi el!

2.4. Kliens telepítése A natív kliens telepítése nem igényel semmilyen program futtatását. Telepítés alatt inkább a kliens gépen való elhelyezést és a munkakönyvtár beállítását értjük. Tekintve, hogy a kliens kezdő csomag mindösszesen két fájlból áll és túl sok helyi változó kapcsolódik a kihelyezéséhez illetve, hogy adott gépen mindösszesen egyetlen egyszer kell elvégezni, nincs értelme installer készítésének. Kiadás: 2014.08.07.

Verzió: 3.10




 Létre kell hozni a kliens gépen egy olyan könyvtárat, amihez az adott felhasználónak, aki használni fogja a Neptun klienst teljes joga van vagy legalább írás és olvasás jogokkal rendelkezik.  Az SDA Informatika Zrt. oldaláról belépés után letölthető az intézmény specifikus kezdő csomag. „Client.zip”. Természetesen az intézmény is készíthet magának belső intraneten közzétett csomagot, ha kényelmetlen a felhasználóknak a honlapra való belépés. Ebben az esetben az alkalmazás szerver „[meghajtó]:\Neptun.NET\Server\ClientFiles” alkönyvtárból a „Neptun_Reloaded.exe” és a „Servers.cfg” fájlra van szükség. Ezen két fájl elegendő ahhoz, hogy a kliens alkalmazás elinduljon, kapcsolódjon a szerverhez, letöltse és létrehozza a szükséges fájlokat és könyvtárakat, majd elinduljon az alkalmazás szerverhez tartozó aktuális verzióval.  Megfelelően beállított könyvtár jogosultság és élő hálózati kapcsolat esetén, ezen két lépés után használható a Neptun natív kliens alkalmazás. Későbbiekben az alkalmazás minden komponense automatikusan frissül. A frissítési folyamat semmilyen kézi beavatkozást nem igényel.

2.5. Hálózati beállítások A Neptun natív kliens működéséhez szükséges hálózati beállításnál mindösszesen egyetlen port engedélyezéséről beszélünk. Ez a port az alkalmazás szerver „ServerConfig.xml” fájlban beállított port. Ez általában a 22222-es port. Természetesen ettől el lehet térni, ha az intézmény belső szabályrendszere ezt megkívánja. Ebben az esetben szem előtt kell tartani azt, hogy ha ez a port módosításra

kerül

a

„ServerConfig.xml”-ben

akkor

azt

változtatni

kell

a

„[meghajtó]:\Neptun.NET\Server\ClientFiles” alkönyvtárban lévő „Servers.cfg” fájlban is és a Neptun alkalmazás szervert újra kell indítani, vagy a megfelelő paranccsal frissíteni kell a frissítéskor letöltésre kerülő fájlok listáját. Ezek az alkalmazás szerver indításakor bekerülnek a memóriába és csak a megfelelő paranccsal vagy újraindítással frissülnek. Abban az esetben, ha már vannak felhasználók, akik az átállítás előtt elindították a natív klienst, nekik el kell juttatni az új „Servers.cfg” fájlt. Ennek az az oka, hogy az ő kliensük induláskor még a régi porton keresi az alkalmazásszervert. A beállított kommunikációs porton történik a frissítés és az adatforgalom is TCP/IP protokollon keresztül.

Kiadás: 2014.08.07.

Verzió: 3.10




2.6. Neptun címtárszolgáltatás 2.6.1. A címtárszolgáltatás leírása A cél, a Neptun Tanulmányi Rendszerben többféle címtárszolgáltatáson keresztül az autentikálás megvalósítása mind a kliens, mind a webes felületen keresztül. A felhasználók alapadatai és jelszava pedig legyenek szinkronban a címtárban található adatokkal.

2.6.2. A címtárszolgáltatás funkciói A jelenlegi rendszer a Microsoft Active Directory és az OpenLDAP alapú eDirectory szerverre van optimalizálva. A szolgáltatás az alábbi funkciókat kezeli:  felhasználók Neptunba való bejelentkeztetése a címtárszolgáltatás segítségével (csak SSL csatornán keresztül működik);  egyszerre akár több, különböző típusú címtárszolgáltatást nyújtó szervert is képes kezelni;  a létező és új hallgatók/alkalmazottak adatait képes szinkronizálni a címtárba (be lehet állítani, hogy milyen útvonalon vegye fel a hallgatókat és az alkalmazottakat ill. melyik útvonalon keresse őket);  a felhasználók alap adatainak változásakor automatikusan szinkronizálódik a címtárral;  jelszó változtatáskor szinkronban lesz tartva a Neptun adatbázisával (kliensből az adminisztrátornak lehetősége van más felhasználó jelszavának megváltoztatására is);  felhasználó törlésekor a címtárban le lesz tiltva (nincs fizikai törlés);  a címtár szerverhez rendelt tanúsítványt képes a Neptun szerver ellenőrizni;  ha nem működik a szolgáltatás, akkor be lehet állítani, hogy ettől függetlenül a Neptun adatbázisát használja bejelentkeztetésre.

Kiadás: 2014.08.07.

Verzió: 3.10




2.6.3. A címtárszolgáltatás paraméterei Az MS AD és az eDirectory szervereken az alábbi funkciók vannak megvalósítva: Funkciók Neptunba bejelentkeztetés Jelszóváltoztatás Új felhasználók felvétele Felhasználói adatok szinkronizálása Felhasználók törlése Tanúsítvány ellenőrzése Több szerver kiszolgálása

Microsoft Active Directory

eDirectory

* * *

Megjegyzés *: Csak bizonyos feltételek teljesülése esetén: létre kell hozni egy NeptunAccount nevű kiegészítő sémát, amiben benne kell lennie az employeeID-nak (ebben tároljuk a neptun kódot) ill. egy UserEnabled boolean típusú attribútumot, amivel lehet állítani a felhasználó aktívságát.

2.6.4. A címtárszolgáltatás működése A szolgáltatás az alábbi folyamatokat valósítja meg: Neptunba való bejelentkeztetés:  A Neptun szerver megvizsgálja, hogy elérhető-e a címtár szerver. Ha nem elérhető, akkor az „AD_NEM_MUKODIK_NEPTUN_BEJELENTKEZTETES” rendszerparaméterrel lehet beállítani, hogy I értéke esetén a Neptun adatbázisában tárolt jelszóval jelentkeztessen be vagy jelezzen ki hibát. („Az autentikáló rendszer jelenleg nem elérhető! Kérjük, próbálkozzon később!”)  Ha a bejelentkezéskor Domain név\Felhasználói név formátumban akar bejelentkezni (pl. Egyetem\MintaAladar), akkor megvizsgálja a rendszer, hogy létezik ilyen néven beállított (DomainName) szerver a konfigurációban. Ha igen, akkor közvetlenül megpróbálja bejelentkeztetni. Ha nem sikerült a bejelentkezés vagy nem találja meg a megadott domain-t, akkor hibaüzenetet küld. („Érvénytelen felhasználónév vagy jelszó”).  Ha a bejelentkezéskor csak a felhasználói nevet adta meg, akkor a konfigurációban megadott szervereken megy végig sorban: o Ha adott szervernél a konfigurációban be van állítva a domain neve, akkor megpróbál a jelszóval együtt bejelentkeztetni. Ha nem sikerül, akkor nézi a következő szervert.

Kiadás: 2014.08.07.

Verzió: 3.10




o Ha adott szervernél nincsen beállítva a Domain név tulajdonság (DomainName), akkor megkeresi a bejelentkezési azonosítója alapján a felhasználót (címtárban: CN vagy UID alapján). Ha nem találja, akkor neptunkód alapján próbálkozik (címtárban: employeeID). Ha itt sincs, akkor nézi a következő szerveren. Ha egyáltalán nem találja, akkor hibaüzenet. („Érvénytelen felhasználónév vagy jelszó!”) o Van lehetőség arra, hogy a konfigurációs állományban megadott paraméterrel beállítsuk,

hogy

a

címtár

szerveren

belül

hol

keresse

a

hallgatót

(StudentStoragePath) ill. az alkalmazottat (EmployeeStoragePath). Ha nincs beállítva, akkor az alapértelmezett elérést veszi (DefaultLDAPRootPath). Mindkét esetben az összes, hierarchiában alatta lévő szinten is keresni fog. o Ahhoz, hogy lehessen felhasználókat keresni a címtárban két lehetőség van:  vagy egy olyan felhasználót (Bind DN-t) deklarálunk, akinek joga van a kereséshez és akinek a nevében ezt meg lehet tenni.  vagy a hozzáférés-vezérlési listákban (ACL – Access Control List) beállítani az adott gyökér DN-ben (konfig fájlban: DefaultLDAPRootPath), hogy lehessen vendég (anonymous) felhasználóként keresni  Ha nincs domain név megadva és nincsen a fenti két lehetőség közül valamelyik deklarálva, akkor egy hibaüzenetet küld a rendszer a bejelentkezéskor. („Az autentikáláshoz nem megfelelőek a beállítások! Kérjük értesítse a lokális rendszergazdát!”) o A megtalált felhasználót megpróbálja bejelentkeztetni a megadott jelszót felhasználva. Ha nem sikerült a bejelentkeztetés, akkor hibaüzenetet dob. („Érvénytelen felhasználónév vagy jelszó!”) o Mivel a kommunikáció csak SSL csatornán keresztül működik, lehetőség van beállítani tanúsítvány ellenőrzést is. (NeedValidateCertificates) Ebben az esetben a címtárhoz rendelt tanúsítványt fogja csak elfogadni a neptun szerver. A neptun szerver gépen a címtárhoz tartozó tanúsítvány a CurrentUser-nél kell legyen megtalálható! Jelszóváltoztatás (saját és másik felhasználónak): Mind a neptun kliensben megváltoztatott jelszót (akár a saját jelszavát vagy más hallgató/alkalmazott jelszavát), mind a neptun weben megváltoztatott jelszavát automatikusan szinkronizálja a rendszer a címtárba. Folyamata:  Először a bejelentkeztetéshez hasonlóan megkeresi a felhasználót a címtárban;  Majd egy olyan felhasználó nevében, akinek van joga hozzá, megtörténik a tényleges jelszóváltoztatás. Mivel csak bizonyos szabályok (domain policy) mellett lehet elvégezni a

Kiadás: 2014.08.07.

Verzió: 3.10




változtatást (ChangePassword), ezért valójában jelszó beállítást végez a szerver (SetPassword);  Ha nem felel meg a címtárban megadott jelszószabályoknak, akkor egy hibaüzenetet kap a felhasználó. („A jelszó nem felel meg a jelszó beállítási követelményeknek!”) Felhasználó adatainak szinkronizálása:  Címtár szerveren nem létező felhasználók felvétele: Lehetőség van az összes hallgató (Neptun kliens: Hallgatók felület, AD szinkronizáció gomb) ill. alkalmazott (Neptun kliens: Alkalmazotti adatok felület, AD szinkronizáció gomb) felvételére, akik még nem léteznek a címtárban ill. a Neptunban új felhasználó felvételekor a címtárba automatikusan szinkronizálódnak. Ha több címtár szerver van definiálva, akkor mindig a legelsőt fogja használni. Folyamata: o az összes felhasználót összegyűjti, akik még eddig nem voltak szinkronizálva; o megkeresi a biztonság kedvéért a felhasználót a címtár szervereken; o ha nem találja meg, akkor felveszi a felhasználót (ehhez persze olyan DN kell, akinek van joga felhasználót létrehozni!):  ha be van állítva a konfigurációs állományban, akkor a hallgatót a StudentSynchronPath útvonalra;  az alkalmazottat az EmployeeSynchronPath útvonalra;  ha nincs valamelyik beállítva, akkor veszi az alapértelmezett gyökér útvonalat (DefaultLDAPRootPath) és azon belül a Neptun Users szervezeti egység (organizational unit) alá veszi fel. o az alábbi attribútumokat menti a neptun szerver a címtárba: Neptun attribútumok Vezetéknév Keresztnév Teljes név Neptunkód

Microsoft Active Directory SN givenName displayName description és employeeID

Bejelentkezési azonosító Bejelentkezési azonosító@domain név

sAMAccountName userPrincipalName

Kiadás: 2014.08.07.

Verzió: 3.10

eDirectory (OpenLDAP) SN GN displayName description és employeeID (ez az attribútum nem létezik, ezért egy NeptunAccount kiegészítő sémában létre kell hozni!) CN




o a konfigurációban beállítható distinguishednamemask alapján generálja ki a DistinguishedName attribútumot. Ha nincs beállítva, akkor alapértelmezetten „Bejelentkezési azonosító” formátumban generálódik ki; o a konfigurációban beállítható descriptionmask alapján generálja ki a teljes nevet. Ha nincs beállítva, akkor alapértelmezetten „Vezetéknév Keresztnév (Neptunkód)” formátumban generálódik ki; o a

konfigurációban

beállítható

displaynamemask

alapján

generálja

ki

a

DisplayName attribútumot. Ha nincs beállítva, akkor alapértelmezetten „Előtag Vezetéknév Keresztnév (Neptunkód)” formátumban generálódik ki; o továbbá a felhasználót normál típusúként menti el, ami azt jelenti, hogy nincs beállítva a következő bejelentkezéskor kötelező jelszóváltoztatás (ezt nem is szabad beállítani, mert gondot okozhat a neptunos bejelentkezéskor) és engedélyezve van (MS AD attribútum: userAccountControl = 512, eDirectory attribútum: UserEnabled = TRUE); o Mivel a neptun rendszerben eltárolt jelszavak titkosítva vannak, visszafejtésük nem lehetséges. Emiatt teljesen új jelszó lesz generálva minden újonnan felvett felhasználónak. Az új jelszó formátuma: NeÉÉÉÉHHNN, ahol a ÉÉÉÉHHNN a születési évet, hónapot és napot jelenti. (ha a hónap vagy a nap egyszámjegyű, akkor 0-val egészíti ki).  Létező felhasználói adatok módosítása: Ha neptun kliensben egy címtárban létező felhasználó adatai megváltoznak (vezetéknév, keresztnév, bejelentkezési azonosító), akkor ezen adatok a címtárba is szinkronizálódnak. Folyamata: o megkeresi a felhasználót a címtárban; o ha nem találta meg valamilyen okból, akkor az előző ponthoz hasonlóan fel fogja új felhasználóként venni; o ha megtalálta, akkor a megváltozott tulajdonságot átvezeti a címtárba.  Felhasználó törlése: o Ha a neptun kliensben törölnek egy felhasználót, akkor először megkeresi a felhasználót a címtárban; o ha megtalálta, akkor a címtárban a felhasználót letiltja (nem lesz fizikai törlése, csak logikai). Vagyis MS AD esetén a userAccountControl értékét 514-re lesz állítva, eDirectory esetén a UserEnabled lesz FALSE értékre állítva;

Kiadás: 2014.08.07.

Verzió: 3.10




2.6.5. A címtárszolgáltatás beállítása Az SDA.ConfigEditor alkalmazással lehet a neptun szerveren és weben beállítani a paramétereket. Az Active directory config tulajdonság alatt az ADProperty-re kattintva lehet egyszerre akár több címtár szervert beállítani. Egy címtár szerverhez az alábbi tulajdonságokat lehet felvenni:  Az ActionType tulajdonság beállításával lehet vezérelni azt, hogy az összes AD szerveren csak autentikálni lehessen jelszó változtatással (OnlyAuthentication érték) vagy új felhasználót is lehessen felvenni ill. az adatait változtatni (FullSynchron érték). Alapértelmezetten Onlyauthentication érték van beállítva.  ActiveDirectoryType: két értéke lehet: MSActiveDirectory (Microsoft Active Directory), eDirectory;  LDAPHostName: a címtár elérése (pl: ldap.de.niif.hu)  LDAPPort: az SSL csatorna portja (pl: 636)  AdminUserName: a jelszóváltoztatáshoz és a felhasználók adatainak szinkronizálásához szükséges egy DN teljes elérési útjának megadása, akinek joga van ezekhez a funkciókhoz (ha nincs megadva, csak bejelentkeztetni lehet)  AdminPassword: a fenti DN-hez tartozó jelszó  DomainName: MS AD esetén ha meg van adva, gyorsabban lehet bejelentkeztetni a felhasználókat  DefaultLDAPRootPath: az alapértelmezett elérési útvonal. Ha nincs megadva a hallgatókra/alkalmazottakra érvényes útvonal, akkor az ezalatt található Neptun Users szervezeti egység (OU, organizational unit) hierarchia alatt fogja keresni a felhasználókat. (Pl.: cn=Admin,ou=system,dc=egyetem,dc=hu vagy cn=Admin,o=system,c=egyetem,c=hu)  EmployeeStoragePath: az összes alkalmazottat ezen a szinten keresi (ha nincs kitöltve, akkor a defaultldaprootpath útvonalat veszi figyelembe)  StudentStoragePath: az összes hallgatót ezen a szinten keresi (ha nincs kitöltve, akkor a defaultldaprootpath útvonalat veszi figyelembe)  EmployeeSynchronPath: az összes új alkalmazottat ide fogja felvenni (ha nincs kitöltve, akkor a defaultldaprootpath útvonalat veszi figyelembe)  StudentSynchronPath: az összes új hallgatót ide fogja felvenni (ha nincs kitöltve, akkor a defaultldaprootpath útvonalat veszi figyelembe)  NeedValidateCertificates: „True” esetén a címtárhoz kapcsolt tanúsítványt összehasonlítja a CurrentUser alatt található tanúsítványokkal, ha nem egyezik, akkor nem fogja engedni az adott szerveren a műveleteket. Ha értéke „False”, akkor nem ellenőriz. Kiadás: 2014.08.07.

Verzió: 3.10




 DistinguishedNameMask: a distinguishedname (egyedi azonosító) attribútumot fogja a megadott maszk alapján kitölteni szinkronizáláskor. Felhasználható elemek: {vezeteknev} – felhasználó vezetékneve, {keresztnev} – felhasználó keresztneve, {elotag} – felhasználó előtagja, {neptunkod} – neptunkód, {bejelentkezesiazonosito} – bejelentkezési azonosító. Mivel ez egy olyan azonosító, aminek egyedinek kell lenni az egész szerveren, ezért mindenképpen vagy bejelentkezési azonosítót vagy neptunkódot tartalmaznia kell a maszknak. Alapértelmezett: {neptunkod} pl: QB0KEB.  DescriptionMask: a description (leírás) attribútumot fogja a megadott maszk alapján kitölteni

szinkronizáláskor.

Felhasználható

elemek:

{vezeteknev}

–

felhasználó

vezetékneve, {keresztnev} – felhasználó keresztneve, {elotag} – felhasználó előtagja, {neptunkod} – neptunkód, {bejelentkezesiazonosito} – bejelentkezési azonosító. Alapértelmezett: {keresztnev} {vezeteknev} ({neptunkod}), pl: Gipsz Jakab (QB0KEB).  DisplayNameMask: a displayname (megjelenítési név) attribútumot fogja a megadott maszk alapján kitölteni szinkronizáláskor. Felhasználható elemek: {vezeteknev} – felhasználó vezetékneve, {keresztnev} – felhasználó keresztneve, {elotag} – felhasználó előtagja, {neptunkod} – neptunkód, {bejelentkezesiazonosito} – bejelentkezési azonosító. Alapértelmezett: {elotag} {keresztnev} {vezeteknev} ({neptunkod}), pl: dr. Gipsz Jakab (QB0KEB).  ModifySAMAccountNameOnLoginNameUpdate:

tartományonként

engedélyezhetjük,

hogy Neptun-ban változó login név szinkronizálódjon-e AD-ba, (alapértelmezett érték: False).  ModifyUPNSuffixOnUpdate: Létező AD-s felhasználó módosításakor változzon-e a UserPrincipalName suffix is (alapértelmezett érték: True).

2.7. Elektronikus aláírás és számlázás feltételei A Neptun tanulmányi rendszerben van lehetőség elektronikusan archivált dokumentumok készítésére. Ezen funkció használata több feltétel együttes teljesítése esetén lehetséges. A legfontosabb, hogy legyen egy intézmény szintű, elektronikus aláírásra alkalmas, érvényes tanúsítványa az intézménynek. Ezen tanúsítvány beszerzése minden esetben az intézmény feladata. Hiteles elektronikus aláírást, így elektronikus dokumentumot csak érvényes tanúsítvánnyal lehet végrehajtani. Érvényes tanúsítványt Magyarországon a közigazgatás által elfogadott hitelesítés szolgáltatótól lehet beszerezni. Ebből jelenleg 4 darab van Magyarországon.

Kiadás: 2014.08.07.

Verzió: 3.10




A hitelesítés szolgáltató a hitelesítendő személy, szervezet iratainak az ellenőrzése után elkészíti a nevére szóló tanúsítványt. Így garantálja, hogy más nevében elektronikus aláírást ne lehessen készíteni, igényelni. Az elektronikus aláírás az úgynevezett aszimmetrikus titkosítást használ. Ennek lényege, hogy 2 darab összetartozó kulcsunk van, egy titkos és egy publikus kulcs. A titkos kulcsot védenünk kell, hiszen a titkos kulccsal történő aláírásért mi vállalunk jogi felelősséget. A publikus kulcsot viszont szabadon

odaadhatjuk

bárkinek,

hogy

megismerje és ellenőrizhesse az aláírásunkat. Ez természetesen nem szükséges lépés. A hitelesítés szolgáltató egy ilyen kulcspárt ad nekünk. A

kulcspár

nyilvános

kulcsát

hívjuk

tanúsítványnak. Ebben benne van a nevünk, az egyéb

adataink,

amelyeket

a

hitelesítés

szolgáltató hitelesített. Ez azonosít minket az elektronikus világban. Az ehhez a tanúsítványhoz tartózó magánkulccsal pedig elektronikus aláírást készíthetünk. A titkos magánkulcs egy számsor, ahhoz nem tartozik megjelenítő felület.

2.7.1. Médiumok A tanúsítványok tárolására két elfogadott módszer van. A legegyszerűbb elnevezés a szoftveres és a hardveres tanúsítvány, illetve kulcs. A szoftveres tanúsítvány vásárlásakor egy pfx, p7b vagy p12 kiterjesztésű állományt kapunk a hitelesítés szolgáltatótól. Ebben az állományban benne van a tanúsítványunk és a titkos kulcsunk is! Ezért ilyen állományokat nem szabad senkinek sem küldeni, továbbadni, mert illetéktelenek a nevünkben hiteles dokumentumokat állíthatnak elő! Ez az állomány jelszóval védett, de ennek a védelme nem kielégítő, így a fenti figyelmeztetés ennek ellenére megszívlelendő. A kapott szoftveres kulcsunkkal ellátott CD lemezt ajánlatos páncélszekrényben tartani.

Kiadás: 2014.08.07.

Verzió: 3.10




A másik típus a hardveres tanúsítvány. Ebben az esetben a titkos kulcsunkat egy hardver eszköz tartalmazza, egy chipkártya, vagy egy USB kulcs, vagy bármilyen egyéb hardver a hordozó. Ennek a lényege, hogy a saját titkos kulcsunkat tőlünk is védik. A titkos kulcsot nem tudjuk leolvasni, letölteni a hardver eszközről. Az eszköz úgy van megtervezve, hogy fizikai kísérletre megsérüljön még a kulcs megszerzése előtt. Így ez nagyobb biztonságot biztosít, mint a szoftveres kulcs. Azonban hogyan tudunk elektronikus aláírást készíteni, ha semmilyen módon nem tudjuk megszerezni a saját titkos kulcsunkat? A válasz nagyon egyszerű. Nem a kulcsot kell „leszednünk” az eszközről, hanem az aláírandó adatot kell az eszközre küldenünk. Az eszköznek saját processzora van, amely elvégzi az aláíró műveleteket. Szoftveres tanúsítvány esetén ezt a műveletet a PC processzora végzi. Az eszköz ezen funkcióját PIN szám védi, hasonlóan a bankkártyákhoz. Az eszköz csak akkor készít elektronikus aláírást, ha helyes PIN kódot kapott. A kártya alapú eszközök megtévesztésig hasonlítanak a bankkártyákhoz, azzal az eltéréssel, hogy nem mágnes csík, hanem chip van a kártyában. A kezelésük is hasonló. Az igazán nagy baj akkor van, ha a PIN kódunk és a kártyánk egyszerre veszik el, jut illetéktelenek kezébe. Ezt lehetőleg kerüljük. A Neptun.NET számára előnyösebb a szoftveres kulcs, így a kártyánkat nem kell a szerverteremben hagynunk, hogy a Neptun.Net aláírásokat készíthessen. Sőt javallott, hogy kártyánkat soha ne hagyjuk felügyelet nélkül.

2.7.2. Típusok Tanúsítványok másik jellemzője, hogy kinek állították ki. Ez lehet személyes, szervezeti, vagy szerver tanúsítvány. Személyes tanúsítványt magánszemélyek igényelhetik. Szervezeti tanúsítványt cégek, intézmények. De ebben az esetben is szükséges egy természetes személy, mint aláíró megnevezése, akit a szervezete felhatalmaz az elektronikus aláírás készítésére. A harmadik kategória a szerver tanúsítvány, amikor egy személy vagy szervezet tulajdonában lévő számítógépet „hatalmazunk” fel az elektronikus aláírás készítésére. Ebben az esetben nem kell megadnunk természetes személyt. Ilyen jellegű tanúsítványok esetén a számítógép önállóan, emberi beavatkozás nélkül képes elektronikus aláírás készítésére. A Neptun.NET esetében javasolt a szervezeti tanúsítvány igénylése, hiszen itt minden aláírási folyamatot egy operátornak kell indítania, és felügyelnie.

Kiadás: 2014.08.07.

Verzió: 3.10




2.7.3. Telepítés Windows operációs rendszerekben található egy tanúsítványtár és egy titkos kulcs tár. A Neptun.NET rendszer ezeket a tárakat kezeli. Ezért a kapott szoftveres tanúsítványt kell a szerver gépre telepíteni. A kapott pfx, p7b vagy p12 állományra kell kettőt klikkelni. Ekkor egy telepítési folyamat indul el. Meg kell adnunk a fájl jelszavát.

Az alsó két kijelölő négyzetet üresen kell hagyni. Az első egy figyelmeztető ablakot definiál, amely jelzi, ha valamilyen alkalmazás használni akarja a tanúsítványt aláírásra. Ez szerverek esetén nem ajánlott, mert emberi közreműködést igényel, így sajnos nem alkalmazható. A második kijelölő négyzet pedig a titkos kulcs exportálását definiálja. Amennyiben exportálhatóvá tesszük a kulcsunkat, bárki, akinek joga van belépni az adott gépre, el tudja lopni a titkos kulcsunkat. Viszont ha nem engedélyezzük az exportálást, akkor a kulcs belekerül a Windows kulcs tárába, és onnan soha többet nem tudjuk kinyerni. Ebben az esetben maga a Windowsos számítógép

Kiadás: 2014.08.07.

Verzió: 3.10




lesz a hardver kulcs. Aláírásokat csak azon a számítógépen végezhetünk. Természetesen az installálást több gépen is elvégezhetjük. Installálás után töröljük a pfx, p7b vagy p12 állományokat, és lehetőleg páncélszekrényben tároljuk ezeket az állományokat az installálás után. A Windows authentikácóra is ügyeljünk, hogy illetéktelenek ne kapjanak jogosultságot a szervergépekre. Nagyon fontos, hogy azzal a felhasználóval legyünk belépve és végezzük el a telepítést, aki a Neptun.NET szolgáltatást futtatja, mert csak így fogja tudni használni a szolgáltatás a tanúsítványt. Különböző felhasználók nem is látják egymás tanúsítványait.

2.7.4. Kompromittálódás Kompromittálódásnak hívjuk a titkos kulcsunk elvesztését. Ebben az esetben haladéktalanul hívjuk a hitelesítés szolgáltatónkat, ahol az azonosítás után a tanúsítványunk visszavonásra, letiltásra kerül, hasonlóan a bankkártyánkhoz. A gyakorlatban egy nyilvános visszavonási listára írnak fel minket, így az elvesztés utáni aláírások érvénytelenek lesznek. A visszavonás előtti aláírások érvényesek maradnak. Az elvesztés és a bejelentés között készült jogtalan és illetéktelen aláírásokért mi nekünk kell sajnos a felelősséget vállalnunk.

2.7.5. Elektronikus számlázáshoz szükséges beállítások A Windows operációs rendszerben lévő tanúsítványok közül meg kell adnunk azt a tanúsítványt, amellyel a Neptun.NET elektronikus aláírásokat készíthet. Ezt az aláíró szervezet és a tanúsítvány sorszáma adja meg. Nemzetközi megállapodások alapján ez a két információ együttesen egyedi. A hitelesítés szolgáltatók nevei egyediek a teljes világon, valamint minden hitelesítés szolgáltató köteles sorszámozni az általa kiadott tanúsítványokat. A Neptun.Net rendszerben ezt is, mint minden konfigurációt az SDA.ConfigEditorban beállítani. Az ide vonatkozó rész a „Xades options”. Emellett a saját adataink kitöltése is szükséges, például aláíró neve, aláírás helye stb. Ezek kitöltése egyértelmű. További szükséges paraméter az intézmény másolási szabályzatának egyedi URI-ja. A 13/2005-ös IHM rendelet előírja, hogy minden papíralapú dokumentum elektronikus másolatának készítésekor

Kiadás: 2014.08.07.

Verzió: 3.10




a másolatkészítőnek saját szabályzattal kell rendelkeznie és ezt az aláírás készítésekor meg kell adni. Az elektronikus aláírásokat időbélyeggel kell ellátni. Az időbélyeg egy további aláírás a dokumentumon, amit egy hitelesítés szolgáltatóhoz hasonló szervezet, az időbélyeg szolgáltató helyez el a dokumentumon. Így garantálható az elektronikus dokumentum keletkezési ideje. Az SDA Informatika Zrt. szerződésben áll időbélyeg szolgáltatókkal, így külön szerződés kötése nem szükséges. A paraméterezésnél emiatt meg kell adni az időbélyeg szerver elérhetőségét, valamint az ügyfél azonosítót, aminek a segítségével az időbélyeg kérések az egyes ügyfelekhez rendelhetők, így összesíthetőek, naplózhatóak. Ezt az egyedi ügyfél azonosítót Az SDA Informatika Zrt. adja ki ügyfelei részére. Minden olyan esetben, amikor egy intézmény aláírást készítő szervert készül beállítani a rendszerbe, tájékoztatnia kell az SDA Informatika Zrt.-t. Ennek az az oka, hogy csak az adatbázisban rögzített IP című szerverek kapnak időbélyeget. Az időbélyegzéshez szükséges tanúsítványokkal kapcsolatosan a 2.8.2. „Tanúsítványok elektronikus számlázáshoz” c. fejezetben még talál további információkat!

2.8. Tanúsítványkezelés Neptun.NET rendszerekben Ez csak egy összefoglaló fejezet a Neptun.NET egységes tanulmányi rendszer, illetve a hozzá kapcsolódó egyéb rendszerekhez. A legtöbb itt leírt információ a dokumentum más fejezeteiben is megtalálható.

2.8.1. Tanúsítvány Neptun.NET kiszolgáló futtatásához A Neptun.NET alkalmazás- és webszerverek futtatásához szükség van az SDARootCertificate telepítésére, ez letölthető a Neptun.NET termékportálról. A telepítőprogramot csak el kell indítani, és néhány másodpercen belül értesít arról, hogy a telepítés sikeres volt, vagy már fenn volt a tanúsítvány. Minden Neptun kiszolgálóra telepíteni kell!

Kiadás: 2014.08.07.

Verzió: 3.10




2.8.2. Tanúsítványok elektronikus számlázáshoz Alkalmazásszerver beállítása: Ehhez egy szervezetszintű, fokozott biztonságú aláíró tanúsítványra van szükség. A dokumentumok az alkalmazásszerveren készülnek el. Az aláíró tanúsítványnak az alkalmazásszerveren kell lennie telepítve, mégpedig úgy, hogy a Neptun.NET alkalmazásszerver (középréteg-szerver) futtató felhasználójának a tanúsítványtárban a „Személyes tároló”-jából, vagy granttal elérhető legyen. Ez kétféleképp érhető el: 1) A tanúsítványt a futtató felhasználó nevében kell telepítenünk. Ez esetben a „Szolgáltatások” kezelőben („services.msc”) be kell állítanunk az alkalmazásszerver futtató felhasználóját. Ezen felül a Neptun.NET alkalmazásszerver könyvtárára (és annak gyermekobjektumaira) adjunk a futtató felhasználónak írás/olvasás jogosultságot! -

vagy

2) Fel kell jogosítani a futtató felhasználót a telepítő személy (account) tanúsítványtárolójának elérésére. Erre alkalmas a WinHttpCertCfg nevű alkalmazás, amely letölthető a Microsoft weboldaláról. A felhatalmazás a következőképp történik: winhttpcertcfg -g -c CURRENT_USER\My -s a_cert_CN_attribútuma –a felhasználó

például: winhttpcertcfg -g -c CURRENT_USER\My -s "PÉLDA EGYETEM" –a "Hálózati szolgáltatás" winhttpcertcfg -g -c CURRENT_USER\My -s "PÉLDA EGYETEM" –a "Network Service"

Amennyiben a tanúsítvány gyökértanúsítványa (Root certificate) és a hitelesítésszolgáltatói tanúsítványa (Root Certificate Authority, CA) nem található meg a tanúsítványtárolóban, a tanúsítványlánc „törött” lesz, ez esetben a kiszolgálóra fel kell telepíteni a kibocsátó által közreadott főtanúsítványt, és CA-t is! Hallgatói webszerveren (ha szükséges): Hallgatói weben csak akkor kell elvégezni a beállítást, ha a hallgatók számára szeretnénk biztosítani számlagenerálást! Ehhez egy szervezetszintű, fokozott biztonságú aláíró tanúsítványra van szükség. A dokumentumok a webszerveren készülnek el. Az aláíró tanúsítványnak a webszerveren kell lennie telepítve, mégpedig úgy, hogy a Neptun.NET web alkalmazáskészlet futtató felhasználójának a „Személyes tároló”-jából, vagy granttal elérhető legyen. Ez kétféleképp érhető el:

Kiadás: 2014.08.07.

Verzió: 3.10



-


A tanúsítványt a futtató felhasználó nevében kell telepítenünk. Ez esetben a „IIS kezelőjében” („inetmgr.exe”) be kell állítanunk a hallgatói webhez

tartozó

alkalmazáskészlet futtató felhasználóját. Az alkalmazáskészlet „speciális beállítások” menüpont alatt, az „Identitás” paraméterben adhatunk meg tetszőleges lokális felhasználót, mint az IIS worker processz futtatója. Ezen felül a Neptun.NET webek könyvtárára (és annak gyermekobjektumaira) adjunk a futtató felhasználónak írás/olvasás jogosultságot; vagy : 1) Fel kell jogosítani az IIS-t futtató felhasználót a telepítő személy tanúsítványtárolójának elérésére. A metódus megegyezik az alkalmazásszerver esetén leírtakkal. Amennyiben a tanúsítvány gyökértanúsítványa (Root certificate) és a hitelesítésszolgáltatói tanúsítványa (Root Certificate Authority, CA) nem található meg a tanúsítványtárolóban, a tanúsítványlánc „törött” lesz, ez esetben a kiszolgálóra fel kell telepíteni a kibocsátó által közreadott főtanúsítványt, és CA-t is! Alkalmazásszerver (ha szükséges, webszerver) paraméterezése: Hallgatói weben csak akkor kell elvégezni a beállítást, ha a hallgatók számára szeretnénk biztosítani számlagenerálást! A tanúsítvány telepítése után be kell állítani attribútumokat a konfigurációs állományában az SDA.ConfigEditor.exe alkalmazás segítségével. A számlázás szempontjából a „xades config options” attribútum csoport elemeit kell módosítanunk: Attribútum neve Kötelező Leírás CertificateIssuerName tanúsítványból a kiállítójának neve, CertificateSerialNumber a tanúsítvány sorozatszáma, a tanúsítványból kell kimásolni, CertificateStoreName alapértelmezett tároló a "My", ezen ne változtassunk! City a település neve, ahová az intézmény be van jegyezve, ClientID az SDA által kiadott kliensazonosító, az időbélyeg lekérésekhez van szükség rá, CopyMaker a másolat kiadó szervezet neve (intézménynév), CopyPolicyURI az intézmény másolatkészítési szabályzatának URI-ja, Country az ország neve, ahová az intézmény be van jegyezve, CreateSignedCertificate készülhet-e elektronikus adóigazolás, csak akkor működik, ha a „CreateSignedDocument" engedélyezve van. CreateSignedDocument készülhet-e elektronikusan aláírt dokumentum PaperSize a generált PDF állományok papírmérete PdfMetaDataAuthor dokumentum készítője PdfMetaDataTitle, dokumentum címe PdfMetaDataComment, megjegyzés Kiadás: 2014.08.07.

Verzió: 3.10



NEPTUN ÜZEMELTETÉS dokumentum tárgya az intézmény irányítószáma időbélyeg prioritás - maradjon a default értéken 5 intézmény állam/megye true, ha tesztrendszer, false, ha éles üzemi kiszolgáló időbélyegszerver címe: http://service1.sdakft.hu:8081/

PdfMetaDataSubject PostalCode Priority StateOrProvince TestMode TimeStampServerURI Tanúsítvány időbélyegzéshez:

Tájékoztatjuk a Neptun pénzügy modulját használó, elektronikus, vagy elektronikusan archivált számlát előállító Ügyfeleinket, hogy a számlákhoz új időbélyeg került kibocsátásra, melynek használatához két új tanúsítvány telepítésére van szükség minden kiszolgálóra, amelyen számlát készít(het) a Neptun! A „NetLock Minősített Eat. (Class Q Legal) Tanúsítványkiadó” tanúsítványt csak egyszerűen fel kell telepíteni: https://www.netlock.hu/index.cgi?minositett&ca=cqlca&lang=HU&tem=ANONYMOUS/kulcsjegyzok/adatok.tem

A

NetLock

Arany

(Class

Gold)

Főtanúsítvány

esetén

fontos,

hogy

a

megbízható

gyökértanúsítványok közé kerüljön: https://www.netlock.hu/index.cgi?ca=gold&lang=HU&tem=ANONYMOUS/kulcsjegyzok/adatok.tem

A

főtanúsítványokról

a

2.8.3.

„Főtanúsítványok,

hitelesítés-szolgáltatók”

c.

fejezetben

részletesebben is lesz szó.

SSL tanúsítványok webszerverekhez (https protokoll) A webszerverekhez kiszolgálónként 1-1 db SSL szervertanúsítványra van szükség. A Neptun.NET hallgatói- és oktatói-webalkalmazásai már megkövetelik az SSL titkosított HTTPS csatornán történő működést. A https binding miatt a szerver publikus címéhez tartozó domainnévnek meg kell egyeznie a tanúsítványban szereplő FQDN-nel. (Fully qualified domain name). Amennyiben megelégszünk a szerver beépített önaláírt („self-signed”) tanúsítvánnyal, a tanúsítványkérelem lépései kihagyhatóak. Tanúsítványigénylés-telepítés: Az IIS kezelőt (inetmgr.exe) segítsévével kérelmezhetünk tanúsítványt. A kezelőben bal oldali struktúrafában a gép névére kattintva érhetjük el az adott IIS beállításait. A „Kiszolgáló

Kiadás: 2014.08.07.

Verzió: 3.10




tanúsítványai” menüpont alatt láthatjuk a már feltelepített tanúsítványokat. Kétféle tanúsítványt használhatunk: 1) Önaláírt („self-signed”) tanúsítvány: a számítógép saját maga számára generálja, nincs ellenőrizve hitelesítés-szolgáltató által. Ettől függetlenül használható, de a böngészők tanúsítványhibát jelezhetnek, de ez a titkosított csatorna biztonságát nem befolyásolja. Ezt úgy érhetjük el, hogy a „Műveletek” menüben az „Önaláírt tanúsítvány létrehozása” menüpontra kattintunk, meg kell adnunk egy gépnevet („FQDN”-t), és máris használatra kész a tanúsítványunk. 2) Hitelesített tanúsítvány: valamely hitelesítés-szolgáltató által aláírt tanúsítvány. Amennyiben a hitelesítés-szolgáltató tanúsítványlánca megtalálható a tanúsítványtárolóban, hibát sem fog jelezni sem az IIS, sem a böngésző kliensek. Erről a „Főtanúsítványok, hitelesítésszolgáltatók” fejezetben még részletesen lesz szó. A „Tanúsítványkérelem létrehozása” („Create Certificate Request”) menüpontra kattintva felugró űrlapot kell kitölteni, ajánlott legalább 2048 bites „Microsoft RSA Schannel”-t választani kriptográfiához. A kérelemet („CSR”-t) egy szöveges állományba kell mentenünk, és továbbítanunk az aláíró hitelesítésszolgáltatónak, amelyre válaszként egy általuk aláírt „pfx/pkcs12” formátumú tanúsítvány kapunk. Ezt az „Importálás” menüpont alatt tudjuk feltelepíteni. Tanúsítvány használatba vétele: Az egyes tanúsítványok az egyes webhelyekhez („website”) rendelhetjük – ezekből több is lehet egy webkiszolgálón. A kezelőben a webhely nevére kattintva az adott webhelyre vonatkozó beállításokat tartalmazó menüket és parancsikonokat láthatjuk. A „Kötések” („Bindings”) menüpontra kattintva érhetjük el a webhely-cím-protokoll összerendelő felületet. Itt adhatunk hozzá egy „https” kötést a webhelyhez. A hozzáadás során a legördülő-listából kiválaszthatjuk a gépre telepített tanúsítványok közül az általunk használni kívántat, illetve a hozzárendelt kiszolgálóportot. A port alapértelmezett értéke tcp/443, ezen ne változtassunk, ha nem feltétlenül szükséges, mert a klienseink előtti tűzfalakat általában a tcp/80-as (http) és tcp/443-as (https) portok felé vannak nyitva. A kiválasztott tanúsítvány neve fogja meghatározni, hogy milyen HTTPS fejléccel küldi majd ki az IIS a kérésekre a válaszokat, a gép publikus címéhez regisztrált FQDN-nek erre a névre kell mutatnia! Amennyiben a tanúsítványkérelem nem ezen a kiszolgálón készült (más webkiszolgálón készítette a kérelmet, vagy webes űrlapon a hitelesítés), úgy egy PFX/PKCS12 tanúsítány-csomagot. A csomag tartalmaz egy X.509 szabványú tanúsítványt, és a hozzá tartozó privát kulcsot.

Kiadás: 2014.08.07.

Verzió: 3.10




2.8.3. Főtanúsítványok, hitelesítés-szolgáltatók Amennyiben a tanúsítvány gyökértanúsítványa (Root Certificate) és a hitelesítés-szolgáltatói tanúsítványa (Root Certificate Authority, CA) nem található meg a tanúsítványtárolóban, a tanúsítványlánc „törött” lesz, ez esetben a kiszolgálóra fel kell telepíteni a kibocsátó által közreadott főtanúsítványt, és CA-t is, valamint biztosítanunk kell, hogy ezeket a tanúsítványokat az intézmény rendszerének felhasználói is elérhessék. A „törött” tanúsítványláncot sárga, felkiáltójeles emblémával jelölik a rendszerek. Az önaláírt („self-signed”) tanúsítványok is ilyenek! Különböző böngészők (illetve azok különböző verziói) más-más hitelesítés-szolgáltatók tanúsítványait ismerik el megbízhatóként. A böngésző által nem tartalmazott CA-kat a felhasználók kézzel vehetik fel a megbízható legfelső-szintű hitelesítés-szolgáltatók közé! Amelyet nem találnak meg a megbízható legfelső-szintű hitelesítés-szolgáltató tárolóban, tanúsítványhibát fognak jelezni, illetve „Nem biztonságos weboldal”-ként fognak a webhelyre hivatkozni – de természetesen a hibaüzenet ellenére az SSL titkosított kapcsolat felépül, és működik. A kapcsolat biztonságát ez nem fogja befolyásolni. A Windows Server 2008, Windows 7 és Windows Vista rendszerek alapértelmezetten rendszeres időközönként frissítik a „Legfelső szintű hitelesítés-szolgáltatók” tárolóban található Root, és RootCA tanúsítványokat. Azok a tanúsítványok, amelyek nem találhatóak meg alapértelmezetten a tárolóban, a frissítések során törlődnek. Ez kikapcsolható a „Csoportházirend” („Group Policy Editor”) szerkesztő programban („gpedit.msc”), a bal oldali struktúrafában:

Kiadás: 2014.08.07.

Verzió: 3.10




Ez alatt a jobb oldali listában található egy „Legfelső szintű tanúsítványok automatikus frissítésének kikapcsolása” / „Turn off Automatic Root Certificates Update” paraméter, amit állítsunk át „Engedélyezve” / „Enabled” státuszra! Ezzel megelőzhető, hogy törlődjenek az általunk feltelepített gyökértanúsítványok.

2.8.4. FIR tanúsítványok 2.8.4.1. Aláíró tanúsítvány – kliens oldali aláírás esetén A FIR csomagok aláírásához egy névre szóló, minősített aláíró-tanúsítvány szükséges, amelyhez azonosító kártya tartozik. 2012. január 1.-től a törvényi változások értelmében már csak SHA-256 lenyomatú tanúsítványt lehet használni elektronikus aláírásra, minden SHA-1 lenyomatú minősített aláíró tanúsítvány visszavonásra került! Különböző szolgáltatóktól származó tanúsítványok telepítése más és más! Ezen tanúsítványok és a kártyaolvasó telepítésére vonatkozó leírást, instrukciókat, technikai segítséget a tanúsítvány kibocsátójától kérhetnek az intézmények! A FIR aláíráshoz szükséges tanúsítványt a FIR csomagokat hitelesítő felhasználó (általában intézményi vezető) számítógépére kell telepíteni, a tanúsítványhoz tartozó kártyaolvasóval együtt. A tanúsítványt a felhasználó személyes tárolójába kell telepíteni. Általánosságban erre a Kiadás: 2014.08.07.

Verzió: 3.10




tanúsítványra is igaz, hogy a hozzá tartozó főtanúsítványoknak (Root Certificate) és hitelesítésszolgáltató (Root CA) tanúsítványnak is elérhetőnek kell lennie. Amennyiben a tárolóban „törött láncot” talál, szerezze be az említett tanúsítványokat a kibocsátótól! A FIR csomagok aláírásához egy NeptunDotNetFirSigner alkalmazást kell telepíteni szintén az aláíró személy gépére, a legfrissebb alkalmazás letölthető a Neptun Termékportálról. Alapértelmezetten a „C:\Program Files\SDA\NeptunDotNetFirSigner” mappába települ, ha telepítéskor más útvonalat nem adtunk meg neki. Fontos, hogy a „FIRSigner.NET.exe.config” állományban a „supportedRuntime version” attribútum megfelelően legyen .Net 4.0 Framework-re átállítva, értéke „v4.0.30319” legyen! <startup> <supportedRuntime version="v4.0.30319" /> …

2.8.4.2. Aláíró tanúsítvány – szerver oldali aláírás esetén A Neptun.NET tanulmányi rendszer őszi verziójától kezdve lehetőséget biztosít a rendszer a FIR konténerek szerver-oldali aláírására is. Ez esetben egy fokozott biztonságú aláíró, közigazgatásban is használható ügyfél-tanúsítvány segítségével írhatja alá a FIR-konténereket. Ezt a tanúsítványt a Neptun alkalmazásszerver gépre, kell feltelepíteni, az alkalmazásszerver service-t futtató felhasználó saját tanúsítványtárába, majd a konfiguráció-szerkesztő alkalmazás (SDA.ConfigEditor) segítségével az alábbi paramétereket kell beállítani a „FIR szerver tanúsítvány” szekcióban:  IssuerName: a tanúsítvány kibocsátó neve;  SerialNumber: a tanúsítvány sorozatszáma;  StoreName: a tanúsítvány-tároló neve – ez „My” legyen, hiszen a futtató felhasználó saját tanúsítványtárába javasolt a tanúsítványt telepíteni. Ellenőrizze, hogy a tanúsítványlánc minden eleme feltelepítésre kerüljön! (ld.: „Főtanúsítványok, hitelesítés-szolgáltatók” c. fejezetben írtakat) Ügyeljen arra is, hogy az IssuerName és SerialNumber paraméterek értékében, sem előtte, sem utána ne maradjon „space”, illetve „whitespace” – ezek másolás során nem tűnnek el!

Kiadás: 2014.08.07.

Verzió: 3.10




2.8.4.3. FIR kommunikációs csatornával kapcsolatos állományok A FIR kommunikációs csatornáinak használata Neptun szerver-konfiguráció szempontból nem vonz magával feladatokat. Az Educatio az alábbi állományokat bocsátja az intézmények rendelkezésére, amelyeket az alkalmazásszerver „FIR” alkönyvtárába kell bemásolni:  intézménykód.tab: kapcsolódási paraméterfile, ebben van lekódolva a FIR-kiszolgáló elérési útja, illetve a maximális konténerméret,  intézménykód.kdb: kulcsadatbázis állomány, ebben van lekódolva az intézmény és a FIR dekódoló felhasználójának nevei,  intézménykód.sth: password-stash állomány,  intézménykód.jks: kulcsadatbázis-állomány, ez tartalmazza a csatornatanúsítványt,  _adatok.txt: a FIR központ által generált „kliens” felhasználót és jelszavát tartalmazó információs állomány. Az SDA által közreadott SDA.FIR.Configurator program segítségével szerkeszthetjük a kdbállományt. Itt az alapértelmezett „kliens” felhasználót kell átírnunk arra a felhasználóra, aki futtatja az alkalmazásszervert, ezáltal fog tudni kapcsolódni az alkalmazásszerver futtató-felhasználója a FIR-központi kiszolgálójához a WebSphere MQ kliensen keresztül. Az MQ kliens telepítése a Neptun.NET Üzemeltetési dokumentációjában részletesen be van mutatva.

2.8.4.4. FIR aláírás metódusának kiválasztása A Neptun kliensben az „Adminisztráció” menüben a „Paraméterek (95800)” felületen keresse meg a FIRALAIRAS paramétert, ennek állítsa be az értékét az alábbiak szerint:  „0”: beállítás esetén nem jelenik meg a konténer aláíró ablak,  „1”: beállítás esetén a konténerek a kliens oldali aláírással hitelesíthetőek,  „2”: beállítás esetén a konténereket szerver oldali aláírással lehet hitelesíteni.

2.9. Kapcsolat a Diákhitel-rendszerrel A 2013 nyári Neptun-verziótól kezdődően a Diákhitel rendszerhez egy közvetlen, tanúsítvány-alapú titkosítással rendelkező csatorna beállítása szükséges. Az intézményi tanúsítványokat a Diákhitel központ generálja le és juttatja el az intézmények számára. Az intézmény részéről három fontos beállítás szükséges:

Kiadás: 2014.08.07.

Verzió: 3.10




 Kommunikációs csatorna biztosítása,  Tanúsítvány telepítése a web- és alkalmazás-szerverekre,  Tanúsítvány konfigurálása a Neptun-rendszerben. A kommunikációs csatorna: Az éles szerviz címe: „https://diakhiteldirekt.hu:8443/services”, a tesztrendszeré pedig: „https://ddtr.diakhitel.hu:8443/services”. A tesztrendszer esetén nem csak a szerverek, hanem a tesztelő gépek publikus IP címét is el kell küldeni a DiákHitel Központ számára, illetve az intézményi tűzfalon is engedélyezzék a kifelé irányuló forgalmat ezen címek irányába! Telnettel ellenőrzizze le, hogy elérhető-e a szolgáltatás! A titkosító tanúsítvány telepítése: Az alábbi screenshotokon láthatja, hogyan lehet beállítani a tanúsítvány-elérését a Neptun.NET webalkalmazásnak. Ehhez indítsa el először az „IIS Manager” alkalmazást, lépjen az „Alkalmazáskészletek / Application Pools”-ra a gyökérben, keresse meg a Neptun-t futtató alkalmazáskészlet nevét és jegyezze fel:

Ezután indítson egy szolgáltatáskezelőt („services.msc”) nézze meg, illetve jegyezze fel, hogy ki a futtató felhasználója a Neptun.NET alkalmazásszervernek. Ha az alapértelmezett „Local system” rendszerfelhasználó jogával fut, állítsa be egy valódi lokális, vagy tartományi felhasználóra a futtatóját!

Kiadás: 2014.08.07.

Verzió: 3.10




Indítson egy MMC-konzolt parancssorból, vagy a „Start menü => Futtatás”-ból! Itt a „Beépülő modul hozzáadása/eltávolítása / Add/Remove snap-in”-t válassz a File menüből, majd ott pedig a „Tanúsítványok / Certificates”-t, ahogyan az alábbi képeken láthatja:

Kiadás: 2014.08.07.

Verzió: 3.10




Az „Add” gomb megnyomására kiválaszthatja, hogy Személyes / My User Account, Szolgáltatásfiók / Service Account vagy Számítógépfiók / Computer Account tanúsítványkezelőjét kívánja megnyitni. Válassza a „Számítógépfiók”-ot!

Majd válassza ki, hogy a lokális gép tanúsítványtárához nyisson konzolt:

Kiadás: 2014.08.07.

Verzió: 3.10




Navigáljon a bal oldali fában a „Személyes / Personal => Tanúsítványok / Certificates” tárolóba, majd jobb gombbal kattintson az „Az összes feladat / All tasks => Importálás… / Import” menüpontra a lebegőmenüben:

A megnyíló filetallózóban keresse meg a Diákhitel Központtól kapott tanúsítványt:

Kiadás: 2014.08.07.

Verzió: 3.10




Adja meg a hozzá tartozó jelszót, illetve jelölje meg a kulcsot exportálhatóként, illetve, hogy a tanúsítvány kiegészítő tulajdonságai is legyenem importálva:

A Next-gombra történő kattintással megerőítést kér a tanúsítvány helyére vonatkozóan:

Kiadás: 2014.08.07.

Verzió: 3.10




Lépjen tovább, egy összefoglalást láthat:

Ezután már a sikeres telepítésről kell értesülnie:

Kiadás: 2014.08.07.

Verzió: 3.10




A DiákHitel Központtól kapott .pfx állomány tartalmaz egy gyökértanúsítványt is, ezt helyezze be a „Legfelső

szintű

hitelesítésszolgáltatók

/

Trusted

Root

Certificates”

tárolóba.

A

gyökértanúsítványokkal kapcsolatban olvassa el az Üzemeltetési dokumentáció „Főtanúsítványok, hitelesítésszolgáltatók” c. fejezetét! Keresse meg a tanúsítványt! Fel kell jogosítania a Neptun.NET alkalmazásstervert futtató felhasználót és a webalkalmazáshoz tartozó alkalmazáskészlet virtuális felhasználóját a tanúsítványhoz történő hozzáférésre. Kattintson rá jobb gombbal, keresse meg a „Az összes feladat / All tasks => Titkos Kulcsok kezelése /Manage Private Keys” menüpontot a lebegőmenüben!

Válassza ki a „From this location” sorban, a „Helyek / Locations” gomb megnyomásával a futtató gépet, a névnél pedig adja meg az alkalmazáskészlet futtató felhasználójának a nevét ilyen formában:

„IIS

AppPool\Alkalmazaskeszletneve”!

AppPool\DefaultAppPool”,

„Tesztkeszlet”

esetén:

Pl.:

DefaultAppPool

„IIS

esetén:

„IIS

AppPool\Tesztkeszlet”!

Az

alkalmazásszervert futtató felhasználót pedig tallózással fogja tudni kikeresni, hiszen az egy valódi felhasználó, így látszik a listában! Ügyeljen a „Hely” kiválasztására tartományba léptettett kiszolgáló esetén (lokális gép, vagy tartomány)!

Kiadás: 2014.08.07.

Verzió: 3.10




Majd az alkalmazáskészletnek és az alkalmazásszerver futtató felhasználónak adjon „Full control” jogot:

Majd nyissa meg a tanúsítványt a konzolban, illetve a Neptun alkalmazásszerver, illetve webalkalmazások (hallgatói-, oktatói web) konfiguráció-szerkesztőjét („SDA.ConfigEditor.exe”)! Állítsa be a Diákhitel rendszer elérését a Server Options alatt található „DiakHitelServiceURL” paramétert:

Kiadás: 2014.08.07.

Verzió: 3.10




A képen látható URL a TESZT DiákHitelService URL-je tesztrendszer esetén ezt állítsák be! Éles rendszer esetén: („https://diakhiteldirekt.hu:8443/services”). A tanúsítvány adatai közül szükség lesz a kibocsátóra (issuer), és a tanúsítvány sorozatszámára (serial)! Ügyeljen rá, hogy ha a tanúsítványról másolja ezeket az adatokat, a Windows nem látható vezérlőkaraktereket is átemel a másolás+beillesztés során. Vagy „kézzel” írja be a ConfigEditor-ba az értékeket, vagy távolítsa el az értékek elejéről és végéről a nem látható karaktereket, szóközöket! A sorozatszámot nem szükséges 2 karakterenként tagolni, a tagoló-szóközök eltávolíthatóak!

Másolja be ezeket az értékeket a konfig editor „Diákhitel tanúsítvány” szekcióba, a „DH_IssuerName” a kiállító, a „DH_SerialNumber” a tanúsítvány sorozattára, a „DH_StoreName” pedig a „Local System\My”, hiszen ide helyeztük el a tanúsítványt!

Kiadás: 2014.08.07.

Verzió: 3.10




Az alkalmazásszerver esetén szerviz-újraindításra, a webalkalmazások esetén pedig egy „iisreset”re van szükség a konfigurációs paraméterek életbe léptetéséhez!

Kiadás: 2014.08.07.

Verzió: 3.10




3. Rendelkezésre állás 3.1. Adatbázis üzemeltetése Az adatbázist 7/24 rendelkezésre állás mellett kell üzemeltetni, ha az intézmény ettől eltérően nem rendelkezik. Az adatbázis leállítását 72 órával korábban írásban célszerű jelezni a felhasználók felé, hogy minden érintett fel tudjon készülni a rendszerleállásra. Az adatbázis terhelési mutatóit figyelemmel kell kísérni, és rendellenes működés esetén a legrövidebb időn belül el kell hárítani problémát. Az adatbázisban tárolt adatok logikai és fizikai tárolóiban rendelkezésre álló szabad helyekről információt kell gyűjteni, annak figyelmeztetési értékét 30% illetve kritikus értékét 10%-ra célszerű állítani. Az adatbázisban tárolt objektumokat figyelemmel kell kísérni, azok közül bármelyik állapota megváltozik, akkor a hibát el kell hárítani és szükség esetén értesíteni kell a rendszer fejlesztőjét. A táblaterek kiterjesztése illetve azokhoz történő adatfájlok hozzáadása minden esetben az üzemeltetés feladata, ezt a rendszer nem figyeli, és nem kezeli. Az adattáblák és indexek statisztikáit folyamatosan szinten kell tartani, melyet megfelelő beállítás mellett az adatbázis kezelő rendszer automatikusan elvégez. Amennyiben a táblaterek töredezettsége eléri vagy meghaladja a 25%-ot, úgy az érintett szegmensek újrarendezése illetve a szegmenshez kapcsolódó indexek újraépítése válik szükségessé. Ezen folyamatok erőforrás-igényesek ezért munkaidőben kerüljük futtatásukat.

Az adatbázis és

az alkalmazás szerver között szakadásmentes redundáns hálózat kiépítése javasolt.

3.1.1. Mentés és helyreállítás Az adatok megvédésének és az adatvesztések elkerülésének érdekében nagyon fontos az adatbázis mentés tervének elkészítése. Az adatbázis mentési terv fontosabb feladatai a következők: Beállítások: A megfelelő mentéshez az adatbázis és annak környezetét a telepítési dokumentációnak megfelelően illetve az Oracle ajánlásait figyelem előtt tartva kell kialakítani. Ez magában foglalja a mentésre fenntartott helyeket, a megőrizendő mentések számát és azok titkosítását.

Kiadás: 2014.08.07.

Verzió: 3.10




Ütemezés: A mentéseket végezzük automatizáltan és ne hajtsuk végre azt manuálisan. Az időzítést állítsuk be a megrendelő igényeinek megfelelően, de ügyeljünk arra, hogy azok minden esetben a használaton kívüli időszakban történjenek és a rendszer kiszolgálási teljesítményét ne befolyásolják. A mentések gyakoriságáról a megrendelő ad pontos leírást. Tesztelés: Kötelező elkészíteni a helyreállítási tervet és azokat egy tesztkörnyezeten végrehajtani, hogy meggyőződjünk mentések használhatóságáról egy esetleges sérülés vagy adatvesztés esetén. Ezt a gyakorlatot minimum havonta egy alkalommal érdemes elvégezni. Megfigyelés: Az adatbázis mentése erőforrás-igényes és az adatok növekedésével arányban növekedhet a mentési és helyreállítási idő, ezért a mentésekről folyamatosan riportokat kell készíteni, ami alapján a megrendelő változtathat a mentési stratégián. Visszaállítás: Amikor valóban szükség van a mentésekre, akkor a mentésből a múlt egy adott időpillanatára állítjuk vissza az adatbázist, úgy hogy a mentési katalógusban található bejegyzések alapján a megfelelő mentést visszatöltjük. Helyreállítás: A mentési állományok visszaállítása után az adatbázist még helyre kell állítani, hogy ne a mentési időpillanattól folytatódjon az adatbázis életciklusa, hanem a leállás előtti pillanatba kerüljön. Ehhez a folyamathoz az archív és online naplókat kell használni.

3.1.1.1. Beállítások Az adatok tárolására fizikai redundancia alkalmazása szükséges. A tranzakciós naplófájlokat minimum két logikai példányban, külön lemezen kell elhelyezni illetve a minden egyéb az adatbázis gyártó által ajánlott megoldás elfogadható. Az online tranzakciós naplókat a felülírás előtt el kell menteni legalább két külön helyre. A mentésekhez helyreállítási katalógus használata ajánlott, ellenkező esetben a kontrolfájlban tárolt bejegyzések megőrzési értékét 14 napra ajánlott beállítani. A konkrét beállításokat minden esetben a működtető környezet paramétereihez kell igazítani.

3.1.1.2. Ütemezés Az adatok mentését heti ciklusban ismételjük, azaz minden hét első napja előtti napon készítsünk az adatbázisról egy teljes nullás szintű online adatbázismentést, majd a hét további napjain kumulatív illetve differenciális inkrementális mentést kell végezni, hogy a mentési halmazok mérete

Kiadás: 2014.08.07.

Verzió: 3.10




csökkenjen és a helyreállításhoz szükséges idő se növekedjen jelentősen. Az ajánlott ütemterv a következő: 7. nap LEVEL 0 INCREMENTAL BACKUP 1. nap LEVEL 1 DIFFERENTIAL INCREMENTAL BACKUP 2. nap LEVEL 1 DIFFERENTIAL INCREMENTAL BACKUP 3. nap LEVEL 1 CUMULATIVE INCREMENTAL BACKUP 4. nap LEVEL 1 DIFFERENTIAL INCREMENTAL BACKUP 5. nap LEVEL 1 DIFFERENTIAL INCREMENTAL BACKUP 6. nap LEVEL 1 CUMULATIVE INCREMENTAL BACKUP Az összes mentéshez a kontrolfájlok és archív naplók mentése is kötelező. A mentések elvégzéshez az adatbázis gyártó által szállított mentőeszköz használata javasolt. A mentéseket külön fizikai helyen kell tárolni, annak tárolási formája szabadon választható, azok megőrzési rendjéről megrendelő köteles nyilatkozni. Az ütemezés során gondoskodni kell az meghatározott mentési renden túli fájlok törléséről. A mentési katalógus nyilvántartja az obsolete objektumokat. A mentések megtartását ajánlott úgy szervezni, hogy egy héten belül bármelyik időpontra visszaállítható legyen az adatbázis, és legalább havonta 1 teljes mentést tartson meg!

3.1.1.3. Tesztelés A mentések helyességéről az éles indítás előtt kötelessége az üzemeltetőnek meggyőződni, úgy hogy az éles rendszertől minden tekintetben független tesztkörnyezeten az elkészített mentésekből visszaállítást majd helyreállítást végez. A mentésről illetve a helyreállításról jegyzőkönyv készítése szükséges melyben fel kell tüntetni a teljes helyreállítási időt mely magában foglalja a mentések külső tárolóeszközről való betöltését, a visszaállítást valamint a helyreállítást. A teljes helyreállítás mellett el kell végezni az adatsérülésből történő helyreállítási tesztet is. A teszt elvégzéséhez az egyik adatfájl kikényszerített sérülését kell végrehajtani majd a mentésekből annak helyreállítását elvégezni. A helyreállítási tesztről szintén jegyzőkönyvet kell készíteni, melynek tartalmazni kell a sérült adatblokkok számát és annak javításához szükséges időt.

3.1.1.4. Megfigyelés A megfigyelés jelentősége a mentési idők és a generált terhelés folyamatos ellenőrzése. A mentési idők növekedéséből vagy csökkenéséből következtetni lehet a rendszerben bekövetkezett átlagos

Kiadás: 2014.08.07.

Verzió: 3.10




használattól eltérő eseményekről. Amennyiben az adatbázis méretében jelentős mértékű eltérés tapasztalható, úgy azonnal meg kell tenni a szükséges lépéseket ennek a feltárására, szükség esetén értesíteni kell a rendszer fejlesztőit, hogy az adatnövekedés vagy adatcsökkenés oka felderítésre kerüljön. Amennyiben nincs rendellenes működés a rendszerben és a mentési idők jelentősen változnak úgy az adatbázis szerver vizsgálata szükséges. A mentések gyorsítása érdekében a mentő eszköz megfelelő paraméterezése szükséges, mint például több mentési szelet készítés illetve a mentés több szálon történő futtatása, valamint a mentési cél szinkron vagy aszinkron üzemeltetése. A megfigyelésre az adatbázis gyártója nyújt riportkészítő eszközt.

3.1.1.5. Visszaállítás A helyreállítás alapfeltétele, hogy a mentéshez tartozó fájlok rendelkezésre álljanak és azok a lehető legrövidebb idő alatti visszamásolása lehetséges legyen. A visszamásolást oda kell elvégezni ahová a mentési katalógusban meghatároztuk a mentés helyét. A katalógusban meghatározott helyen két mentés ciklusnyi mentési állományt célszerű megtartani, a gyors visszaállíthatóság érdekében. Az adatbázis leállítását követően a mentőeszköz használatával visszaállítási műveletet kell elvégezni. A megrendelő kérésére az adatbázist a mentési cikluson belüli időpontra is vissza kell tudni állítani.

3.1.1.6. Helyreállítás A helyreállításhoz előbb visszaállítást kell végezni, majd a visszaállított adatbázison kell a mentőeszközzel elvégezni a helyreállítási folyamatot. A helyreállítás során beszélhetünk teljes és részleges helyreállításról. A helyreállítás teljességét minden esetben a bekövetkezett esemény váltja ki. Amennyiben adatsérülés történt, úgy minden esetben a teljes helyreállítás a cél, míg abban az esetben, ha a felhasználók vagy üzemeltetők hibájából történt adatvesztés vagy téves adatbevitel úgy a rendszert birtokló szervezet hoz döntést a helyreállítás időpontjáról.

3.1.2. Adatbázis mentése és helyreállítása Oracle adatbázison Az Oracle alapvetően két működési módot tesz lehetővé. A két működési mód az „Archivelog” illetve a „Noarchivelog” mód. Archivelog módban az adatbázis online tranzakciós naplói folyamatosan mentésre kerülnek így biztosítva az utolsó mentés óta bekövetkezett változások több

Kiadás: 2014.08.07.

Verzió: 3.10




módon történő tárolását. Ebben az esetben lehetőség van az adatbázis fájljainak online mentésére, és a mentésekre lehetőség van rágörgetni a naplókat. A másik lehetőség, hogy az adatbázisunk Noarchivelog módban üzemel, és online tranzakciós naplók felülírásra kerülnek. Ebben az esetben nem tudunk online mentést készíteni csak az adatok logikai exportálására van lehetőség. Ebben az esetben egy adatvesztés esetén csak az export utolsó állapotára lehet visszaállni.

3.1.2.1. Adatbázis mentése NOARCHIVELOG módban A Noarchivelog módot a telepítésnél tudjuk beállítani vagy később az adatbázis leállításával és a megfelelő paraméterek beállításával. Ha az adatbázisról mentést szeretnénk készíteni, akkor az adatbázist le kell állítani, vagy a táblatereket offline állapotba kell tenni. Ha online mentést szeretnénk készíteni, akkor erre az egyetlen megoldásunk az exportfájl gyártása. Az exportfájl az adatbázis meghatározott sémájáról készülhet és annak adatairól egy konzisztens állapotot mutat. Az export fájl elkészítését több felületről is elvégezhetjük, de az általánosan elérhető parancssori megoldást javasoljuk. Ezen művelet elvégzéséhez a következő utasítás kell kiadnunk: C:\expdp.exe [user]/******@[alias] SCHEMAS = [neptun3r] DUMPFILE = neptun3r_export.dpe LOGFILE = neptun3r_export.log DIRECTORY = BACKUP_DIR ESTIMATE = STATISTICS

Az export feladat elvégzése után létrejön az export állomány, mely tartalmazza az éles adatbázis séma összes objektumát és annak adatait.

Ezt a mentési formát célszerű valamilyen tervnek

megfelelően ütemezni, majd a mentési állományt tömöríteni. Az így keletkezett fájlokat bizonyos időnként felülírhatjuk, hiszen itt nincs inkrementális mentésre mód. Amennyiben szükséges vagy a rendelkezésre álló háttértároló kapacitás lehetővé teszi, bizonyos időnkénti mentéseket archiválhatunk.

3.1.2.2. Adatbázis visszaállítása NOARCHIVELOG módban Minden adatállományt és vezérlőállományt vissza kell tölteni a korábbi teljes adatbázismentésből. Ha az Export segédprogramot használtuk az adatbázis mentéséhez, akkor az Import programmal visszatölthetjük az elveszett adatokat. Ez azonban csak egy részleges helyreállítást biztosít és tranzakciókat veszíthetünk.

Kiadás: 2014.08.07.

Verzió: 3.10




3.1.2.3. Adatbázis mentése ARCHIVELOG módban A teleírt naplóállományt addig nem lehet újrahasználni, amíg az ellenőrzési pont be nem fejeződött, és a naplóállomány nem lett archiválva. A vezérlőállomány napló történeti részében egy rekord rögzíti az archivált naplóállomány sorszámát. A példány-helyreállításhoz az adatbázison végzett legutolsó módosítások az online naplóállományokban mindig elérhetők, a lemezhiba utáni helyreállításhoz a régi naplóállományok archivált másolatát is használhatjuk. Az adatbázisnak ARCHIVELOG módban kell futni. Amikor az adatbázist archiváló módba tesszük, akkor a vezérlőállomány is megfelelően módosul. Az automatikus archiváláshoz elindíthatjuk az ARC háttérfolyamatot. Elegendő hellyel kell rendelkeznünk az archivált naplóállományok tárolásához. Az adatbázist megvédi a lemezhiba esetén bekövetkező adatvesztés ellen. Az adatbázist online állapotban is menthetjük. Amikor a SYSTEM-től különböző táblatér lemezhiba miatt megsérül, akkor helyreállításkor az adatbázis többi része elérhető marad, mivel elegendő csak a sérült táblateret kikapcsolni és helyreállítani. Több naplócsoport használata garantálja, hogy az online naplóállományok archiválása befejeződik, mielőtt újra kellene használni őket.

3.1.2.4. Adatbázis mentése ARCHIVELOG módban, RMAN segítségével Archivelog módban futó adatbázist szabályosan Oracle RMAN segítségével menthetjük el, ha online adatbázist mentünk, akkor pedig csak az RMAN javasolt. Az RMAN a mentésekről nyilvántartást vezet, kétféleképp:  katalógusszerverrel,  katalógusszerver nélkül (nocatalog). A katalógusszerver egy távoli Oracle kiszolgáló, ahol egy adatbázist készít az adatbázisszerverünk mentéseiről, nocatalog mód esetén az adatbázis vezérlőállományaiba írja a mentési nyilvántartást. Ez a nyilvántartás az alapja egy esetleves helyreállításnak, illetve visszaállásnak. Csatlakozás RMAN-hoz parancssorból: C:\>rman target sys/sysjelszo@dbtns nocatalog

A „show all” parancs kiadásával megnézheti az RMAN beállítási lehetőségeit: C:\>rman target sys/sysjelszo@dbtns nocatalog HelyreßllÝtßs-kezel§: : Release 11.2.0.1.0 - Production on H. Mßrc. 11 10:29:11 2013 Copyright (c) 1982, 2009, Oracle and/or its affiliates.

All rights reserved.

hozzßkapcsolˇdva a cÚladatbßzishoz: NEPTUN3R (DBID=2596881200) a cÚladatbßzis vezÚrl§fßjljßnak hasznßlata a helyreßllÝtßsi katalˇgus helyett RMAN> show all;

Kiadás: 2014.08.07.

Verzió: 3.10




Az RMAN konfigurßciˇs paramÚterek a db_unique_name NEPTUN3R ÚrtÚkkel rendelkez§ adatbßzishoz: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'C:\ORACLE\ORA11G\DATABASE\SNCFNEPTUN3R.ORA'; # default RMAN>

A legfontosabb paraméterek:  retention policy: mentés-megtartási szabály, ez lehet mentési ablak, vagy redundancia-alapú. Értéke: „to recovery window of X days” vagy „to redundancy X”;  default device type: „disk” vagy „tape” lehet, annak függvényében, hogy lemezre, vagy szalagra történik a mentés;  controlfile autobackup: a mentés során a vezérlőállományokat is mentse-e. Mindenképp javasolt bekapcsolni. Értéke „on” vagy „off”; Ezen kívül tömöríteni, és titkosítani tudja a mentéseket – ez erőforrás-igényes. Mentési szintek:  Teljes mentés („INCREMENTAL LEVEL 0”) – minden adatállományt ment;  Különbözeti mentés („INCREMENTAL LEVEL 1”) – az utolsó mentés óta módosult adatblokkokat menti;  Összegző különbözeti mentés („INCREMENTAL LEVEL 1 CUMULATIVE”) – az utolsó teljes vagy összegző mentés óta módosult adatblokkot menti. Az archivelog állományok mentéséről külön kell gondoskodnunk RMAN-mentés során, illetve a vezérlőállományok mentését is végezhetjük paranccsal. Az RMAN által végrehajtandó mentési feladatokat scriptből is futtathatjuk, ebben az esetben a script filet bármilyen txt-szerkesztővel (pl.: jegyzettőmb, notepad++, stb..) összeállíthatjuk, egy .rcv kiterjesztésű fileban, az alábbi példa szerint:

Kiadás: 2014.08.07.

Verzió: 3.10




RUN { ALLOCATE CHANNEL T1 TYPE DISK MAXPIECESIZE 10G; SET COMMAND ID TO 'rman'; SQL 'alter system archive log current'; BACKUP FORMAT 'D:\Backup\archlog_%t_%s_%p' (ARCHIVELOG ALL DELETE ALL INPUT); BACKUP INCREMENTAL LEVEL = 0 FORMAT 'D:\Backup\backup_%t_%s_%p' (DATABASE INCLUDE CURRENT CONTROLFILE); SQL 'alter system archive log current'; BACKUP FORMAT 'D:\Backup\archlog_%t_%s_%p' (ARCHIVELOG ALL DELETE ALL INPUT); CROSSCHECK BACKUP; CROSSCHECK ARCHIVELOG ALL; DELETE NOPROMPT EXPIRED ARCHIVELOG ALL; DELETE NOPROMPT EXPIRED BACKUP; DELETE NOPROMPT OBSOLETE; }

A mintascript soraihoz egy gyors leírás:  „RUN blokk”: az ebben a blokkban foglaltakat hajtja végre az RMAN.  ALLOCATE CHANNEL T1 TYPE DISK MAXPIECESIZE 10G: lefoglal egy diszk-típusú csatornát a mentéshez. A maxpiecesize opcionális paraméter, ekkorára darabolja fel a mentést. Helyreállítás esetén nem mindegy, hogy mekkora egy többszáz GB-os mentésből kell helyreállítani, vagy csak egy darabjára van szükség (pl.: 1 adatállomány sérülése esetén). Kis adatbázisoknál nincs értelme használni, nagyoknál (ha a mentés nagyobb, mint 40 GB) ajánlott!  „SET COMMAND ID TO RMAN”: elindul a mentési folyamat.  „SQL ’alter systen archivelog current’; ”: a megkezdett redo állományt kiíratjuk egy archivelog állományba.  „BACKUP FORMAT xxxxx (ARCHIVELOG ALL DELETE ALL INPUT)”: minden archivelog állományt elmentünk, a mentetteket letöröljük. A format paraméterrel adhatjuk meg, hová keletkezzenek a mentett állományok, milyen névvel. A filenév egyediségét garantálják a %t, %s, %p paraméterek.  „BACKUP INCREMENTAL LEVEL = X”: az adatbázis mentése, a mentési szint ismertetett megadásával. A format ugyanúgy működik, mint archivelog állományok esetén. Az „INCLUDE CURRENT CONTROLFILE” a vezérlőállományok mentését indítja. Ha az RMAN paraméterek közt nincs a CONTROLFILE AUTOBACKUP engedélyezve, akkor itt legyen kiadva!  ezután a mentés ideje alatt keletkezett archivelog állományokat is elmentjük, utána karbantartó utasítások következnek:

Kiadás: 2014.08.07.

Verzió: 3.10




 CROSSCHECK BACKUP: keresztellenőrzés, megvannak e az RMAN által eddig létrehozott adatbázis-mentés állományok (ott, ahová keletkeztek);  CROSSCHECK ARCHIVELOG ALL: keresztellenőrzés, megvannak e az RMAN által eddig létrehozott archivelog-mentés állományok (ott, ahová keletkeztek);  DELETE NOPROMPT EXPIRED ARCHIVELOG ALL: a mentés-megtartási szabálynak nem megfelelő (lejárt) archivelog-mentések törlése;  DELETE NOPROMPT EXPIRED BACKUP: a mentés-megtartási szabálynak nem megfelelő (lejárt) adatbázis-mentések törlése;  DELETE NOPROMPT OBSOLETE: a mentés-megtartási szabálynak nem megfelelő, érvénytelen mentések törlése. RMAN meghivása scripttel: C:\>rman target sys/sysjelszo@dbtns nocatalog nocatalog cmdfile 'C:\eleresi\ut\RMAN_level_0.rcv' msglog 'C:\eleresi\ut\RMAN_level_0.log'

Ezt a hívást egy .cmd állományba mentve egy batch-filet készíthetünk (külön a teljes, külön az inkrementális mentések számára), ami már pl.: feladatütemezőből is futtatható. Linux esetén egy shell-scriptet készíthetünk, ügyelve az elérési utakra – a Linux-os szintaktikának megfelelően! Ebben az esetben az ütemezést a cron-ra bízzuk!

3.1.2.5. Adatbázis helyreállítása ARCHIVELOG módban Visszatölthetjük a sérült adatállomány egy mentett másolatát, és az archív naplóállományok használatával előregörgethetjük az aktuális pillanatig, mialatt az adatbázis online vagy offline állapotban van.  Visszaállíthatjuk az adatbázist egy megadott időpontig.  Visszaállíthatjuk az adatbázist egy megadott archivált naplóállomány végéig.  Visszaállíthatjuk az adatbázist egy megadott rendszerváltozás számig (System Change Number - SCN).

3.1.2.6. A teljes és a részleges helyreállítás összehasonlítása Amikor lemezhiba utáni helyreállítást végzünk, akkor a mentésből visszatöltött állományokat módosítjuk a naplóbejegyzésekkel az aktuális időpillanatig, vagy a felhasználó által meghatározott korábbi időpillanatig.

Kiadás: 2014.08.07.

Verzió: 3.10




Teljes helyreállításkor naplóbejegyzésekkel vagy növekményes mentéssel felfrissítjük a mentésből visszatöltött állományokat a legutolsó pillanatig. Az archív és az online naplóállományokban lévő összes módosító naplóbejegyzést rágörgetjük az állományokra. Teljes helyreállítást végezhetünk adatbázis, táblatér vagy adatállomány szinten. Részleges helyreállításnál az adatbázist az aktuális időnél korábbra állítjuk helyre. A mentés óta keletkezett naplóbejegyzések egy részét görgetjük csak rá a visszatöltött állományokra. Részleges helyreállítást elsősorban adatbázis szinten végzünk, de táblatér szintjén is lehetséges.

3.1.2.7. Lemezhiba és helyreállítás ARCHIVELOG módban Amikor lemezhiba történik az adatbázissal ARCHIVELOG módban, és szeretnénk helyreállítani a hiba időpontjáig, akkor a következőkre van szükségünk:  az adatbázis archiváló módjának beállítása után készült érvényes mentésből a sérült vagy elveszett adatállományok másolatára;  az összes archivált naplóállományra, ami a felhasznált mentés óta keletkezett;  azokra az online naplóállományokra, amik az utolsó tranzakciók bejegyzéseit tartalmazzák, de még nem lettek archiválva. Helyreállítási lépések Ha az előbb említett állományokkal rendelkezünk, akkor elvégezhetjük a teljes helyreállítást: 1. Győződjünk meg arról, hogy a felülírandó állomány nincs nyitva a visszatöltés alatt. Kérdezzük le a V$DATAFILE és V$TABLESPACE nézeteket az állományok állapotának ellenőrzéséhez. 2. Csak azokat az adatállományokat töltsük vissza, amik elvesztek vagy megsérültek. Ha valamennyi állományt visszatöltenénk, akkor az adatbázisunkat visszavinnénk a mentéskori állapotba. Ne töltsük vissza az online naplóállományokat sem. 3. Csatoljuk vagy nyissuk meg az adatbázist. 4. Állítsuk helyre az adatállományokat a RECOVER paranccsal Helyreállítás ARCHIVELOG módban (Teljes helyreállítás) Ha az adatbázis ARCHIVELOG módban működik, akkor a következő előnyöket és hátrányokat tapasztalhatunk.

Kiadás: 2014.08.07.

Verzió: 3.10




Előnyök:  Csak az elveszett vagy sérült állományokat kell visszatölteni.  Véglegesített adatok nem vesznek el. Az állományok visszatöltése, majd az archivált és online naplóállományok görgetése után az adatbázist az aktuális pillanatig helyreállíthatjuk.  A helyreállítás teljes ideje az állományok visszatöltési, az archivált és az online naplóállományok állományokra görgetési idejéből áll  A helyreállítást akkor is elvégezhetjük, ha az adatbázis nyitva van (kivétel a SYSTEM és az online visszaállítási szegmenseket tartalmazó táblatér adatállományainak helyreállítási esete). Hátrányok:  Rendelkeznünk kell az összes naplóállománnyal, ami az utolsó mentés óta az aktuális pillanatig keletkezett. Ha egy hiányzik, akkor nem tudunk teljes helyreállítást végezni, mivel a naplóállományokat keletkezési sorrendben kell rágörgetni az adatállományokra.

A helyreállításhoz szükséges állományok A V$RECOVER_FILE nézetből lekérdezhetjük a helyreállítandó állományok listáját, és a szükséges helyreállítás kezdőpontját: SQL> SELECT * FROM v$recover_file; FILE# ONLINE ERROR CHANGE# TIME ----- ------- ------ ------- --------2 OFFLINE 288772 21-SEP-Ol

Az ERROR oszlopban a helyreállítás okát láthatjuk, kétféle értéke lehet:  NULL: a helyreállítás oka ismeretlen;  OFFLINE NORMAL: ha helyreállítás nem szükséges. A CHANGE# oszlopban az az SCN (System Change Number) látható, ahonnan a helyreállítást kezdeni kell.

A helyreállításhoz szükséges archivált naplóállományok Az archivált naplóállományokat a V$ARCHIVED_LOG nézetből, a helyreállításhoz szükséges naplóállományokat a V$RECOVERY_LOG nézetből kérdezhetjük le: SQL> SELECT * FROM v$recovery_log;

Kiadás: 2014.08.07.

Verzió: 3.10




THREAD# SEQUENCE# TIME ARCHTVE_NAME ------- --------- --------- --------------------------1 34 21—SEP-O7 /u0l/oradata/archive/arch_34.rdo ... 1 43 21-SEP-O7 /u0l/oradata/archive/arch_43.rdo 1 44 21-SEP-O7 /u01/oradata/archive/arch_44.rdo

A fenti példában láthatjuk, hogy a 2. adatállomány helyreállításához a 34-es naplótól van szükség. A RECOVER parancs A következő parancsokkal lehet az adatbázist helyreállítani:  RECOVER [AUTOMATIC] DATABASE Csak zárt adatbázis esetén használható.  RECOVER [AUTOMATIC] TABLESPACE | Csak nyitott adatbázis esetén alkalmazható.  RECOVER [AUTOMATIC] DATAFILE | Zárt és nyitott adatbázis esetén is kiadható, az „AUTOMATIC” kapcsolóval automatikusan görgeti az archivált és az online naplóállományokat.

Helyreállítás archivált naplók használatával Helyreállításkor az Oracle manuálisan vagy automatikusan is görgetheti a szükséges archivált és online naplókat az adatállományok újraépítéséhez. Mielőtt a rágörgetés megtörténne, az Oracle felajánlja a szükséges naplóállomány nevét.

Az archív naplók visszatöltése más helyre Ha az archivált naplóállományokat nem a LOG_ARCHIVE_DEST paraméter által meghatározott könyvtárba töltöttük vissza, akkor a helyváltoztatásról értesíteni kell az Oracle szervert a helyreállítás előtt vagy közben:  Megadhatjuk a helyet és a nevet a RECOVER parancs promptjánál is:  Használjuk az ALTER SYSTEM ARCHIVE parancsot: SQL> ALTER SYSTEM ARCHIVE LOG START 70 ;

Kiadás: 2014.08.07.

Verzió: 3.10




 Használjuk a RECO VER FROM parancsot: SQL> RECOVER FROM ‘’ DATABASE

Naplóállományok automatikus görgetése  Mielőtt elkezdenénk a helyreállítást végezzük el a kővetkező SQL*Plus parancsot: SQL> SET AUTORECOVERY ON

Írjuk be az AUTO kulcsszót, amikor RECOVER promptot kapunk: SQL> RECOVER DATAFILE 4 ORA—00279: change 308810...03/21/07 17:00:14 needed for thread 1 ORA-00289: suggestion: /u0l/archive/arch_34.rdo ORA-00280: change 308810 for thread 1 is in sequence #34

Specify log: {=suggested | filename | AUTO | CANCEL} AUTO Log applied. ...

• Használjuk az AUTOMATIC opciót a RECOVER parancsban: SQL> RECOVER AUTOMATIC DATAFILE 4 Media recovery complete.

3.2. Katasztrófaterv 3.2.1. Katasztrófaterv szükségessége Katasztrófaterv kialakítása olyan nem kívánt esemény elhárítására irányul, amely az adattovábbító, -tároló és feldolgozó képesség elvesztését okozza, hosszabb időre. Minden ilyen eseményt a továbbiakban katasztrófaként kell kezelni és minden esetben ajánlott követni a jelen dokumentáció utasításait.

3.2.2. Megelőző intézkedések A rendszer üzemeltetése során törekedni kell a katasztrófatűrő környezet kialakítására, a katasztrófák bekövetkezési valószínűségének és a bekövetkezésükkor fellépő kár csökkentésére, valamint a katasztrófa után a folyamatos és rendeltetésszerű működés minél gyorsabb és költségkímélőbb visszaállítására. A gyors és hatékony elhárítás érdekében a telepítési dokumentumokat, adatbázismentéseket, telepítőkészleteket a rendszertől elkülönített helyen ajánlott tárolni. Amennyiben lehetséges és szükséges célszerű olyan szerverpark kialakítása melyen a Kiadás: 2014.08.07.

Verzió: 3.10




rendszer replikációja megtalálható, de a „production” rendszertől földrajzilag eltérő helyen található. Katasztrófa esetén legfontosabb az adatok legutolsó mentésének megléte ezért azok megóvása és rendszeres ellenőrzése kiemelt feladat.

3.2.3. Katasztrófa esetén értesítendő személyek Az intézmény köteles rendelkezni azon személyek nevéről és elérhetőségeiről, akiket katasztrófa esetén értesíteni szükséges, illetve az értesítendő személyek és elérhetőségeik naprakészentartásáról köteles gondoskodni. A riasztási lánc tartalmazzon minden olyan személyt, akik a katasztrófa elhárításhoz feltétlenül szükségesek. A rendszer üzemeltetéséhez az ügyeleti szolgálat megszervezése ajánlott. Ezen kívül az intézmény katasztrófa esetén köteles értesíteni az SDA Informatika Zrt.-t is.

3.2.4. Keletkezett kár felmérése A helyreállítás első lépése a keletkezett kár felmérése, és annak függvényében ki kell dolgozni az azonnali lépések sorrendjét, illetve a párhuzamosan végezhető feladatokat elosztását. Meg kell jelölni azt a felelős személyt és annak helyettesét, aki egy esetlegesen bekövetkezett katasztrófa esetén meghozza a döntéseket.

3.2.5. Helyreállítás A rendszer helyreállítását a hardver környezet javításával, vagy a készenléti szerverek beindításával kell kezdeni. Ezek után az adatbázist a biztonsági mentésből, a mentési dokumentációban leírt helyreállítási módszerrel be kell tölteni majd, vagy ezzel párhuzamosan az alkalmazásokat kell a telepítési információknak megfelelően beüzemelni. A rendszer állapotáról tájékoztatni kell hivatal által megjelölt személyeket.

Kiadás: 2014.08.07.

Verzió: 3.10




4. Teszt rendszerek 4.1. Tesztrendszer fogalma A Neptun.NET egységes tanulmányi rendszer használata során felmerül az igény az új funkciók tesztelésére, illetve a kritikus műveletek teszt rendszerben történő futtatására. A verziófrissítések során a teszt rendszer is karbantartásra kerülhet, de az éles rendszeren keletkezett adatok nem frissülnek. Amennyiben egy új funkció teszteléshez olyan adatokra van szükség, melyek csak az éles rendszerben szerepelnek, szükség van az adatok áttöltésére. Az adatok áttöltése adatbáziskezelő rendszertől függő művelet.

4.2. Tesztrendszer naprakészen-tartása, éles adatok időszakos áttöltése Amennyiben a tesztadatok frissítésére gyakran van szükség, úgy célszerű a folyamatot valamilyen időközönként ütemezett feladatnak beállítani. Az ütemezést lehetőség szerint hajnali időpontra tervezzük be, hogy az éles rendszer működését minél kevésbé terhelje. Az áttöltés előtt fontos ellenőrizni, hogy a teszt illetve éles rendszerek azonos verzión álljanak. Ha a teszt rendszer verziója magasabb (ez a gyakoribb!), akkor az áttöltés után a verziófrissítési folyamatot meg kell ismételni a teszt adatbázison, ellenkező esetben, ha az éles rendszer van magasabb verzión, akkor az áttöltés után a teszt alkalmazás és web-alkalmazás cseréje szükséges.

4.2.1. Adatok áttöltése Oracle adatbázis-kezelő rendszeren A művelet első fázisa egy export fájl készítése az éles adatbázisról. Ezt a folyamatot az Oracle által biztosított Datapump Export (expdp.exe) nevű konzolos alkalmazással javasoljuk elvégezni. Fontos! A Datapump alkalmazások, szerver oldali folyamatok, így a konzol bezárása nem állítja le az exportot vagy importot. Szintén ehhez kapcsolódó információ, hogy a konzol leszakadása esetén úgy tűnhet, hogy lefagyott az alkalmazás, de az a háttérben már befejezte működését. Hosszas várakozás esetén célszerű megvizsgálni az oracle directoryban keletkezett naplófájlt.

Kiadás: 2014.08.07.

Verzió: 3.10




A program megtalálható a szerver vagy kliens oldalon amennyiben a Database Utilities komponens telepítve lett. A Datapump Export minden esetben egy Oracle Directory–ba helyezi el az export állományt, így ha korábban nem hoztunk létre ilyet, akkor ezt is el kell végeznünk. A könyvtár létrehozását a következő parancs kiadásával végezhetjük el (mivel a rendszerhez nincs kötelező sémanév használat, így a példákban szereplő szögletes zárójelben elhelyezett kifejezéseket az adott környezethez kell igazítani!): SQL> SQL> SQL> SQL> SQL>

-- Oracle Directory létrehozása -- Connect sys as sysdba CREATE OR REPLACE DIRECTORY BACKUP_DIR AS 'F:\oracle\export\'; Directory Created GRANT READ, WRITE ON DIRECTORY BACKUP_DIR TO [neptun3r];

A következő lépés az export fájl elkészítése. Az export fájl elkészítését több felületről is elvégezhetjük, de az általánosan elérhető parancssori megoldást javasoljuk. Ezen művelet elvégzéséhez a következő utasítás kell kiadnunk: C:\expdp.exe [user]/******@[alias] SCHEMAS = [neptun3r] DUMPFILE = neptun3r_export.dpe LOGFILE = neptun3r_export.log DIRECTORY = BACKUP_DIR ESTIMATE = STATISTICS [FLASHBACK UTASÍTÁS]

Az export feladat elvégzése után létrejön az export állomány, mely tartalmazza az éles adatbázis séma összes objektumát és annak adatait. Amennyiben az éles és teszt rendszer különböző szerveren vagy adatbázispéldányban helyezkedik el, úgy az elkészült export fájlt át kell helyezni a teszt adatbázisban létrehozott Oracle Directory által meghatározott fizikai helyre. Használatban lévő adatbázisok esetén a kulcsokkal kapcsolódó táblák esetén előfordulhat, hogy az egyik tábla export ideje alatt más, kapcsolódó táblákba már keletkeznek újabb rekordok. Ún. „konzistens”

exportot a FLASHBACK_TIME vagy FLASHBACK_SCN expdp paraméterrel

állíthatjuk be. Első esetben egy adott időpontra, utóbbiban egy megadott „rendszer-változás szám”ra konzisztens állapotot állít elő az expdp. Az alábbi példában a jelenlegi időpillanatra-konzisztens dump készül: C:\expdp.exe [user]/******@[alias] SCHEMAS = [neptun3r] DUMPFILE = neptun3r_export.dpe LOGFILE = neptun3r_export.log DIRECTORY = BACKUP_DIR ESTIMATE = STATISTICS FLASHBACK_TIME=systimestamp

Ha nem a jelenlegi időpillanatra konzisztens állapotot szeretnénk, tetszőleges időpont is megadható:

Kiadás: 2014.08.07.

Verzió: 3.10




FLASHBACK_TIME=”to_timestamp(’2014.06.30 12:21:00', 'YYYY.MM.DD HH24:MI:SS')”

A rendszerváltozás-számot az alábbi SQL paranccsal kérdezhetjük le az Oracle-ről: SQL> select current_scn from v$database;

SCN-konzisztens állapot a FLASHBACK_SCN paraméterrel állítható elő: FLASHBACK_SCN=scnszám

Amennyiben a teszt rendszer használatban van úgy a betöltés előtt meg kell szüntetni a teszt séma kapcsolódásait. Ezt megtehetjük a teszt alkalmazás szerver leállításával. Az áttöltés folytatása az export fájl betöltése. Az export fájl betöltésére az Oracle által biztosított Datapump Import (impdp.exe) nevű alkalmazást használjuk. A betöltés elvégzéséhez létezni kell egy teszt sémának. Amennyiben korábban még nem rendelkeztünk teszt adatbázissal, hozzunk létre egy új felhasználót NEPTUN3R_TEST névvel és az éles sémának megfelelő jogosultsággal. A teszt rendszerhez mindig használjunk külön táblateret. A felhasználók és táblaterek létrehozásának részletes leírása megtalálható a dokumentáció 2. Telepítési információk fejezetében. Az adattáblák egyedi azonosítóihoz szekvenciát használunk, melyet a teszt rendszeren el kell dobni az éles adatok betöltése előtt. Erre azért van szükség, mert az import a létező szekvencia aktuális értékét nem tudja felülírni, viszont ha nem létezik ilyen objektum, akkor létrehozza azt az éles rendszerbeli szekvencia alapján. Amennyiben ezt elmulasztjuk, úgy az teszt rendszeren könnyen egyediségi hibába ütközhetünk, mert az éles rendszer szekvenciája nagyobb értéken áll a feltételezhetően több tranzakció miatt. A teszt rendszer szekvenciájának eldobására használjuk a következő utasítást: SQL> -- Szekvencia eldobása SQL> -- Connect sys as sysdba SQL> DROP SEQUENCE NEPTUN3R_TEST.SEQ_ID_GENERATOR;

A szekvencia eldobása után kezdődhet az export fájl betöltése melyet a következő parancs segítségével végezhetünk el: C:\impdp.exe [user]/******@[alias] SCHEMAS = [neptun3r] DIRECTORY = BACKUP_DIR DUMPFILE = neptun3r_export.dpe LOGFILE = neptun3r_import.log REMAP_SCHEMA = [neptun3r]:[neptun3r_test] REMAP_TABLESPACE = [neptun_dat]:[neptun_test_dat] TABLE_EXISTS_ACTION = REPLACE

Ha az éles és teszt adatbázis külön szerveren lett kialakítva és a teszt rendszeren azonos névvel kerültek kialakításra a táblaterek és

felhasználók, akkor a parancsból elhagyható a

REMAP_SCHEMA és a REMAP_TABLESPACE kifejezés.

Kiadás: 2014.08.07.

Verzió: 3.10




Egy felhasználóhoz több táblateret is használhatunk, ebben az esetben a REMAP_TABLESPACE paraméter mögött vesszővel több táblatér is felsorolható, illetve az is megoldható, hogy az éles rendszerben több táblatérben lévő adatok a teszt rendszerben egy helyre kerüljenek. Ennek a megoldás az, hogy a kettőspont mögötti részen lévő cél táblatér helyre az összes előfordulásnál azonos táblateret adunk meg. Az export és import parancsok részletesebb leírása a 3. Rendelkezésreállás című fejezetben található. Az import befejezése után a teszt rendszer alkalmazás és web szerverei visszaindíthatók és a teszt adatbázis frissítése ezzel befejeződött. Az áttöltés során a Neptun.NET egységes tanulmányi rendszer által készített naplók nem kerülnek áttöltésre!

4.2.2. Adatok áttöltése MSSQL adatbázis-kezelő rendszeren A művelet első fázisa egy backup fájl készítés. A backup fájl készítésére, használjuk a Microsoft SQL Server Management Informatika Zrt. alkalmazását. Ezt a funkciót elérhetjük az Object Explorer\[Server]\Databases\[adatbázisnév] jobb klik Tasks\Back up…

A következő lépésben hozzunk létre egy új adatbázist, majd az előző lépésben készített fájl segítségével állítsuk helyre az újonnan készített teszt adatbázist. Az új adatbázis létrehozását a következő úton érhetjük el. Kiadás: 2014.08.07.

Verzió: 3.10




Object Explorer\[Server]\Databases jobb klik New Database…

A helyreállításhoz álljunk a teszt adatbázis fölé az egérrel és kattintsunk a következő menüpontra: Object Explorer\[Server]\Databases\[adatbázisnév] jobb klik Tasks\Restore\Database…

A helyreállítás sikeres lefutása után állítsuk be a teszt alkalmazás- és web szervereken az új adatbázist a kapcsolatleíróban. Ezzel a teszt rendszer elkészült és használható.

Kiadás: 2014.08.07.

Verzió: 3.10




5. Verzió kihelyezés 5.1. A verzió kihelyezés esemény előzménye A verzió kihelyezés oka három fő tényező lehet. 1. Jogszabályi változás miatt az addigi programlogika nem megfelelő. Ebben az esetben elengedhetetlen a frissítés minden olyan intézménynél ahol az adott jogszabály érinti a tevékenységi kört. 2. Új funkció került a programba. Ilyenkor az intézmény eldöntheti, hogy igényli-e ezt az új funkciót, mely magával vonzza a verzió kihelyezés szükségességét. 3. Programlogikai vagy működési hiba került javításra. Itt abban az esetben van szükség teljes verzió kihelyezésre, ha a javítás érinti az adatbázis struktúrát is vagy olyan sok file módosult a program állományban, ami ezt indokolttá teszi. Ellenkező esetben elegendő manualbuild kihelyezése is.

5.2. Igénylés, végrehajtás, értesítés A verzió kihelyezést minden esetben az intézmény igényli! Abban az esetben, amikor elkészül egy új verzió, az SDA Informatika Zrt. jelzi az intézmények felé, hogy lehetőség van új verzió használatára. Ebben az esetben is szükség van arra, hogy az intézmény jelezze, igényt tart az adott verzióra. Verzió kihelyezés végrehajtásnál kétféle típus létezik.  Az SDA Informatika Zrt. erre felkészített és feljogosított dolgozója távoli kapcsolattal elérik az intézmény szervereit, melyeken elvégzik a szükséges feladatokat, azaz magát a teljes frissítési folyamatot. Ebben az esetben a frissítést végző személy hivatott a frissítés eredményét kiértékelni és az alapműködést (sikeres login a natív és a webes klienseken) letesztelni. Amennyiben a frissítés sikeres, a frissítést végző személy értesítést küld arról az intézményi kapcsolattartónak. Ez az eset csak akkor áll fenn, ha az intézmény rendelkezik üzemeltetési szerződéssel az SDA Informatika Zrt.-vel.  Az úgynevezett független intézmények (akik nem rendelkeznek üzemeltetési szerződéssel az SDA Informatika Zrt.-vel) önállóan végzik el a frissítést. Ebben az esetben az SDA

Kiadás: 2014.08.07.

Verzió: 3.10




Informatika Zrt. erre felkészített és feljogosított dolgozója összeállítja a frissítéshez szükséges állományokat egy meghatározott formátumban, majd elhelyezi azt az intézményi adatforgalom számára fenntartott FTP szerver elkülönített (csak az adott intézmény számára hozzáférhető) könyvtárban. Miután a feltöltés megtörtént értesítést küld az intézményi kapcsolattartónak, melyben egyértelműen leírja a frissítő csomag fontos paramétereit (frissítő script kezdő és befejező száma valamint a build azonosítója). Ebben az esetben a frissítés folyamata csak akkor ért véget, amikor az intézmény visszaküldte a frissítés alatt keletkezett logo(ka)t és az SDA Informatika Zrt. megfelelő dolgozója kiértékelt.

5.3. Verzió- és javítócsomag kihelyezése A Neptun rendszer működéséhez szükséges dll-ek fordítása, titkosítása, komponensek bemásolása, programfájlok előállítása (továbbiakban „build”-elés) az SDA Informatika Zrt. ezen célra felkészített szerverén történik. Ezen szerverről egy erre a célra írt program állítja össze az un. release csomagot. Ezen csomag tartalmazza az:  az alkalmazásszerver frissítő állományát,  a webszerver frissítő állományát,  az adatbázis frissítéshez szükséges állományokat,  a frissítés elvégzését segítő program legfrissebb verzióját. Mivel a frissítő csomag ebben az esetben jól definiáltan egy bizonyos adatbázishoz készül, az adatbázis frissítő script is az adott adatbázis aktuális verziójáról a kívánt verzióra emeléshez szükséges utasításokat tartalmazza. Az így összeállított release-csomag felkerül az SDA Informatika Zrt. FTP szerverére. Erre azért van szükség, mert egy ilyen frissítő csomag ~200MB, amit így lehet a leggyorsabban a frissítendő szerverekre eljuttatni. A folyamatot az SDA által készített „Release.exe” végzi ellenőrzött körülmények között. Amennyiben a verzió kihelyezés nem az alkalmazással történik elképzelhető alkalmazás inkonzisztencia. A program beállításait a mellette található „config.xml” tartalmazza. A beállított paraméterek a frissítés típusától függnek. Ezek az alábbiak lehetnek:  adatbázis kapcsolathoz szükséges paraméterek (ez Oracle ill. MSSQL esetén eltérőek),  alkalmazást futtató Windows service neve (ez az alkalmazás leállításához kell),  frissítendő project neve (a Neptun és a Poszeidon alkalmazást egyaránt képes frissíteni),

Kiadás: 2014.08.07.

Verzió: 3.10




 frissítő könyvtár teljes elérési útja (ebben a könyvtárban keresi a program a zip kiterjesztésű állományokat),  alkalmazás szerver könyvtár teljes elérési útja. Csak lokális lehet másik szerveren található alkalmazás szervert az ott elindított programmal kell frissíteni,  kivétel fájlok listája (azokat a fájl neveket vagy kiterjesztéseket kell felsorolni, amelyeket nem szabad törölni vagy felülírni a szerver állományok másolásakor). Amennyiben a program még nem volt elindítva nincs mellette „config.xml”. Ezt indításkor a program érzékeli is és hibaüzenettel figyelmeztet erre.

Ebben az esetben a program automatikusan a beállítások felülettel indul el, ezzel is jelezve, hogy a megfelelő paraméterek nélkül semmilyen folyamat nem indítható.

Miután beállítottunk minden, az adott frissítéshez szükséges paramétert a „Mentés” gombra kattintva létrejön a „config.xml” fájl. Ekkor kapjuk vissza a kontroll felületet, amin a frissítés

Kiadás: 2014.08.07.

Verzió: 3.10




nyomon követhető lesz. Miközben tart a frissítés a felületen megjelenő üzenetek párhuzamosan egy log fájlba is íródnak. Ennek a fájlnak a neve mindig változik. A fájl név dinamikusan képződik. „Release_[dátum].log” ahol a dátum megegyezik a „Frissítés indítása” gomb megnyomásakor a lokális időponttal. A program csak azokat a komponenseket fogja frissíteni, amelyek a „Frissítés indítása” gomb lenyomásakor be vannak jelölve. A folyamat indítása után sem a beállítási paraméterek sem a frissítendő komponensek nem változtathatók. A frissítőcsomag elkészültéről és ftp szerveren való elhelyezéséről értesítő email megérkezése után az adott szerveren kell készíteni egy könyvtárat ahol a Release.exe dolgozni tud. Továbbiakban ezt a könyvtárat nevezzük „update” könyvtárnak. Célszerű ezt a könyvtárat a „Neptun.NET\Update” névvel létrehozni. Fentebb írtak alapján a Release.exe ide, azaz maga mellé fogja kitömöríteni a továbbiakban szükséges állományokat. Továbbá a frissítés folyamatát és esetleges hibáit naplózó log fájlok is ide fognak képződni. Abban az esetben, ha külön szerveren van az alkalmazás és az adatbázis funkcionalitás, akkor is lehetőség van a frissítési feladatok összevonására. Például az alkalmazás szerveren egy időben lehet az alkalmazás szerver és az adatbázis frissítését. A program automatikus frissülő tulajdonsága miatt a csak alkalmazásszerver frissítésekor is le fog töltődni a dbupdate_[adatbázis típus].zip az update könyvtárba. Ennek az az oka, hogy a Release.exe ebben a tömörített állományban van publikálva és csak így biztosított az automatikus frissülése. Release.exe automatikus frissülése: A program a 2.0.0.0 verziótól képes saját magát frissíteni. Ez csak abban az esetben történik meg, ha a frissítő könyvtár elérési útja meg van adva és ott van dbupdate_[adatbázis típus].zip. A friss Release.exe mindig a dbupdate_[adatbázis típus].zip tömörített állományban kerül közzétételre. A program

indításakor

(amennyiben

a

feltételek

adottak)

összehasonlítja

a

saját

és

a

dbupdate_[adatbázis típus].zip-ben lévő fájl verziószámát. amennyiben ez eltér, akkor üzenetet ad az eltérő verziók kiírásával. Ez alapján el lehet dönteni, hogy kívánjuk e a verzióváltást vagy nem.

Kiadás: 2014.08.07.

Verzió: 3.10




Frissítés indítása előtti ellenőrzés: 2.0.0.9-es verziótól lehetőség van a frissítés indítása előtt ellenőrzést végezni. Ennek az a jelentősége, hogy ha az ellenőrzéskor mindent rendben találunk, akkor a frissítés garantáltan sikeresen fog lefutni. Az ellenőrzés kifejezetten az adatbázis frissítés feltételeit figyeli. Miután elindítjuk a programot, lefut a program frissítése és amennyiben van a konfigurációs állomány beolvasása. Ha nincs konfigurációs állomány, akkor értelemszerűen az ellenőrzés sem lehet sikeres, hiszen nincs ismert adatbázis kapcsolat. Az ellenőrzés kiterjed az aktuális adatbázis verzióra (fő és alverzió egyaránt), a konfigurációs file szerint szükséges adatbázis frissítő állomány meglétére, az állományban található frissítő sql fájl meglétére és megfelelő kezdő verziójára illetve a megjelölt projektre. Az ellenőrzés akkor helyes, ha mind az adatbázis mind az sql fájl kezdő verziója megegyezik, illetve ha minden szükséges fájl rendelkezésre áll. Verziófrissítés release.exe segítségével: 2.0.2.0 számú verziótól a program képes letölteni a release vagy a patch állományokat. Ehhez szükséges, hogy az adott szerver tudjon ftp kapcsolatot létesíteni az SDA Informatika Zrt. ftp szerverével. A „Release csomagok” jelölőnégyzet bepipálása után a program kapcsolódik az ftp szerverre és feltölti az elérhető release csomagok nevét a legördülő listába ahonnan kiválasztható a használni kívánt csomag.

Kiadás: 2014.08.07.

Verzió: 3.10




A Patch ftp szerverről történő letöltésénél nem kell (és nem is lehet) kiválasztani a csomagot. Szeretnénk elkerülni a hibalehetőséget ezért a program megnézi az adatbázis verziót és azt veszi alapul.

Értelemszerűen egyszerre két jelölés nem lehetséges, hiszen ez a jelölés egyben a frissítési folyamatot is definiálja. Azaz vagy verzió, vagy patch kihelyezés történhet. Elképzelhető az, hogy nem lehetséges az ftp kapcsolat felépítése. Ebben az esetben egyik jelölő se legyen bepipálva. A program a megfelelő gomb lenyomásából tudni fogja, hogy release kihelyezést (Frissítés indítása gomb) vagy patch kihelyezést kell végeznie (Patch kihelyezése gomb). Ebben az esetben egy információ jelenik meg, amely figyelmeztet, hogy nincs kiválasztva ftp csomag. Az „OK” gombra

Kiadás: 2014.08.07.

Verzió: 3.10




kattintva a frissítés az update könyvtárban található állományból fog megtörténni. Patch kihelyezés esetén az update könyvtárban kell lennie egy „Patch” könyvtárnak és ezen belül a patch állományok. „Cancel” gombra kattintva a folyamat megszakad és lehetőségünk van a beállítások újbóli megadására módosítására.

Ftp szerverről történő frissítés esetén a működés: 1. a program letölti a kiválasztott komponensekhez szükséges állományokat, 2. letárolja a felület beállításait, 3. újraindítja saját magát, 4. lefrissíti saját magát (ha van eltérés), 5. visszatölti a felület beállításait, 6. elindítja a frissítési folyamatot. Az alkalmazás szerver frissítés lépései: 1. Windows service leállítása (ehhez kell a beállított service név). Erre azért van szükség, hogy a frissítés ideje alatt senki ne tudjon natív klienssel kapcsolódni. Ilyenkor „Hálózati kommunikációs hiba” üzenetet ír a kliens. 2. alkalmazás szerver könyvtár tartalmának törlése. Itt figyelembe vannak véve a Release.exeben beállított kivétel fájlok. 3. az új alkalmazás szerver állományok bemásolása a cél könyvtárba a „server.zip” fájlból. 4. alkalmazásszervert futtató Windows service elindítása. Amennyiben több komponens van megjelölve frissítésre akkor az indítási kérdés csak a folyamat végén kerül elő. Adatbázis frissítés lépései: Minden fájl, ami a frissítéshez szükséges a „dbupdate_[adatbázis típus].zip” –ben található. Ezen állományokat a frissítési folyamat kezdetekor a Release.exe kitömöríti és elhelyezi maga mellett.

Kiadás: 2014.08.07.

Verzió: 3.10




1. adatbázis struktúra módosító verzió script futtatása. A program futtatás előtt ellenőrzi a frissítendő adatbázis verzióját. Amennyiben az adatbázis verziója nem egyezik meg a verzió script kezdő verziójával, akkor a program figyelmeztet erre és leállítja a folyamatot. Ennek az az oka, hogy nem engedélyezett a verziófolytonosság megszakítása. A nagyobb hiba az, ha kimaradnak verzió scriptek. Kisebb gond, de ugyancsak nem kívánatos többször lefuttatni a verzió scripteket. A 2.0.4.7-es verziótól bármilyen sql utasítás futtatása előtt a program ellenőrzi, hogy helyesen van e beállítva az adatbázis-kezelő szoftver karakter kódolása. A folyamat rettentően egyszerű. Egy extra karakterekkel tarkított szöveget kis és nagybetűs formában letárol az adatbázisba, majd lekérdezi azt. Ha a lekérdezés eredménye nem egyezik meg a kiindulási szöveggel hibaüzenet jelzése mellett leállítja a folyamatot. C:\Neptun.NET\Update> sqlplus [user]/[password]@[alias] @.\UPDATE.SQL > update.log

2. kritikus táblákra mutató kényszerek lekapcsolása, 3. a kritikus táblákat lockoló munkamenetek megszűntetése, 4. kritikus táblák tartalmának törlése. C:\Neptun.NET\Update> sqlplus [user]/[password]@[alias] @.\ B_IMPORT_TABLES.SQL >> update.log

5. kritikus táblák betöltése. Oracle adatbázis esetén ezek a kritikus táblák tartalma a „critical.dmp” fájlban vannak és a betöltéshez az Oracle import programját hívja meg a program. C:\Neptun.NET\Update> imp.exe FILE='critical.dmp' FROMUSER=NEPTUN TOUSER=[user] IGNORE=Y CONSTRAINTS=N STATISTICS=NONE INDEXES=N >> update.log

MSSQL adatbázis esetén ezek a kritikus táblákat leíró xml-ekből az SDA Stúdió Kft. által készített „SDA.DataPump.exe”-vel történik. C:\Neptun.NET\Update>

SDA.DataPump.exe

/config:

toreleaseddatabase.xml

>>

update.log

6. kritikus táblákra mutató kényszerek lezárása C:\Neptun.NET\Update> sqlplus [user]/[password]@[alias] @.\ A_IMPORT_TABLES.SQL >> update.log

7. minden érvénytelen tárolt eljárás újrafordítása 8. log ellenőrzése és kiértékelése. 9. az adatbázis frissítés logjainak letárolása adatbázisba.

Kiadás: 2014.08.07.

Verzió: 3.10




Nagyon fontos! Minden frissítés logját kérnénk elküldeni az SDA Informatika Zrt. részére kiértékelés céljából! Abban az esetben, ha nem kapunk információt az intézményi frissítésről, akkor nem tudjuk követni, hogy az intézmény milyen verzión áll. Így nagyon nehéz az intézmény bejelentéseket kezelni.

Patch kihelyezés release.exe-vel A 2.0.4.7-es verziótól a Release.exe nem csak a szerver patch állományokat tudja kihelyezni, hanem az adatbázis javításokat is. Előfordulhat ugyanis, hogy a sql utasításokat kell befutatni ahhoz, hogy a javítás teljes legyen. Ezek az sql file-ok a Patch könyvtáron belül az SQL könyvtárban találhatóak. Elkülönítve az Oracle és az MSSQL, de megkülönböztetve, hogy melyik patch verzióhoz tartoznak. Mivel nem minden patch-ez tartozik sql file ezért nem kell elvárni, hogy az SQL könyvtárban egymást követő verziószámú file-ok legyenek. Viszont a számozásnak nagy jelentősége van. A program külön logika alapján kezeli a patch verziókat. Jelentősége nem csak az, hogy ellenőrzötten lehet kihelyezni a javításokat, hanem az is, hogy a program minden patch-elés után a kihelyezett verziószámot visszaírja az adatbázisba. Ezáltal lehetőség nyílt a kliensből, a help menüben a főverzió mellett a legutoljára kirakott patch verzió kiolvasására is. A Patch ftp szerverről történő letöltésénél nem kell (és nem is lehet) kiválasztani a csomagot. Szeretnénk elkerülni a hibalehetőséget ezért a program megnézi az adatbázis verziót és azt veszi alapul. A használat nem tér el a normál verzió kihelyezéstől és teljesen beleillik az eddig is megszokott patch kihelyezés menetébe. Mindössze annyi a tennivaló, hogy patch kihelyezésnél be kell (lehet) pipálni az adatbázist is, mint frissítendő komponenst. Ebben az esetben csak a jelölő négyzetnek van jelentősége. Az alatta található három rádió gomb állása jelentéktelen a folyamat végkimenetelét tekintve. Mivel ebben az esetben is nagy jelentősége van a beállított karakterkódolásnak, itt is lefut az ellenőrző rutin. Amennyiben eltérés van a javító sql-ek futtatása nem történik meg. Ennek természetesen nyoma van a logban. Offline csomagkihelyzés release.exe-vel A release.exe nem csak a saját maga által letöltött verzió- és patch-csomag kihelyezésére is van lehetőség – de ez esetben a „kézzel” odamásolt csomagok verzió-ellenőrzésének lehetősége odavész, a végrehajtó személy felelőssége, hogy csak megfelelő csomag kerüljön ki! Verzió-kihelyezés

esetén

az

FTP-ről

előzőleg,

a

megfelelő

kezdő-

és

célverzió

(„Release_Neptun/{kezdőverzió}-{célverzió}”) mappából letöltött, szerver (server.zip) és dbupdate (dbupdate_oracle.zip vagy dbupdate_mssql.zip – az intézmény által használt adatbázis-kezelő

Kiadás: 2014.08.07.

Verzió: 3.10




rendszertől függően) csomagot másolja a release.exe mellé, majd indítsa a – „Release-csomag” jelölőnégyzet bejelölése nélkül – a kihelyezést az előzőekben a „verziókihelyzés”-nél leírtak szerint. Patch-kihelyezés esetén az FTP-ről előzőleg, a „Release_Neptun/Patches/{verzió}” megvefelelő verziószám mappából letöltött {verzió}.zip állományt és {verzió}_patches.txt-t másolja a release.exe mellett található „Patch” könyvtárba. Ha még nem létezik ilyen, hozza létre. Indítsa a – „Patch letöltés” jelölőnégyzet bejelölése nélkül – a kihelyezést a „patch-kihelyezés”-ben leírtak szerint.

5.4. Licenszállomány kihelyezésének és cseréjének folyamata A Neptun.Net Egységes tanulmányi rendszer használata licenszhez kötött, melyet minden egyes futó alkalmazás és web szerver mellett elhelyezett .n3l kiterjesztésű fájl tartalmaz. A fájl határozza meg, hogy az intézmény mely modulokat mennyi ideig használhatja. Általánosságban elmondható, hogy az intézmények minden hónapban új licensz-állományt kapnak, melynek cseréjét az alábbiakban leírt módon kell elvégezni. A licenszfájl kiterjesztése minden esetben „.n3l” a fájl neve eltérő lehet, de általában a licensz érvényességének kezdő és végdátumát tartalmazza elválasztó karakterek nélkül. A licenszállomány cseréjéhez a release.exe-t használhatja. A beállítások között szerepel egy intézménykód, ez feltétlenül legyen kitöltve: Az intézménykód általában az intézmény rövidített neve, vagy akroníma. A kihelyezéshez pipálja be az „Alkalmazás szerver” és/vagy „Web szerver” jelölőnégyzetet, attól függően, hogy hová szeretné kihelyezni a licenszet. Minden mást automatikusan el fog végezni a release.exe, melyről a képernyőn, illetve naplóállományban is értesíti Önt.

Kiadás: 2014.08.07.

Verzió: 3.10




5.5. LOB típusú oszlopok konverziója A verziófrissítések során előfordulhat, hogy egyes oszlopok típusa BLOB(IMAGE)-ról CLOB(NTEXT)-ra változik. Ezt a szerkezeti változást, adatbázis oldali konverzióval nem lehet garantált adatvesztés nélkül elvégezni, így a BLOB típusú oszlopok átnevezésre kerülnek, és új CLOB típusú oszlopok készülnek a verzió scriptek által. A típuskonverzióhoz a frissítés után el kell indítani a mellékelt SDA.LOBConverter.exe programot, mely az átnevezett BLOB típusú oszlopból előállítja a CLOB értéket. Amennyiben a verziófrissítés alkalmával használni kell a konvertálót, úgy azt külön jelezni fogjuk, illetve a program használatához, a verziófrissítések során mellékeljük a konfigurációs xml állományt, ami tartalmazza az érintett táblák és oszlopok felsorolását. A program használata: SDA.LOBConverter.exe lobconverter.xml [server path]

ahol a lobconverter.xml kötelező, ez tartalmazza a konvertálandó oszlopok listáját, a szerver path, ha nincs megadva akkor az aktuális könyvtár, ahonnan az exe indítása történt.

Kiadás: 2014.08.07.

Verzió: 3.10




A szerver path egy valódi Neptun alkalmazás szerver gyökérkönyvtára (C:\Neptun.NET\Server), ahol a ServerConfig.xml található. A program a következő fájlokat fogja keresni:  serverpath\ServerConfig.xml  serverpath\Assemblies\SDA.Neptun.TheFramework.dll Ebből adódik, hogy nincs szükség adatbázis kapcsolódási paraméter megadására, mert azt az adott szerver konfigurációjából fogja venni, így fontos, hogy a paraméternél a megfelelő alkalmazás szerver legyen megadva. A program nem készít naplót, így annak kimenetét a mellékelt parancs alapján egy fájlba kell kivezetni, mely segítségével ellenőrizhető, hogy a konverzió sikeresen megtörtént vagy sem. Példa: C:\SDA.LOBConverter.exe lobconverter.xml c:\Neptun.NET\server >> NeptunLOBConvert.log

A lobconverter.xml felépítése az alábbiak szerint alakul: <SourceColumn>[átnevezett BLOB típusú oszlop] [új CLOB típusú oszlop]

MSSQL adatbázisok esetén IMAGE adattípust konvertálunk NTEXT típusra, a fent leírtakkal teljesen azonos módon.

5.6. FIR XML szétbontás, konténerek tömörítése A 2013 nyári verzióval egyidőben kiadásra került egy „XML_Szetbontas.exe” nevű alkalmazás is. Ez lehetővé teszi, hogy kliens felületen az összeállított FIR konténerek tartalma kereshetővé, listázhatóvá válik. A „szétbontás” opcionális, nem kötelező megtenni. Csak a 2013 nyári Neptun verzió kihelyezése után futtatható le, amennyiben szeretné használni a funkciót, ez esetben egyszeri futtatás szükséges, az új verzióval összeállított konténerek tartalma már eleve böngészhető lesz. A program többszöri futtatása nem okozhat problémát.

Kiadás: 2014.08.07.

Verzió: 3.10




Az alkalmazásból két x32 és az x64 verzió is készült. Az ftp-ről letöltött zip file tartalmát csomagolja ki az alkalmazásszerver könyvtárába. A zip állomány tartalma két file:  XML_Szetbontas.exe,  XML_Szetbontas.exe.config. Amennyiben Oracle adatbázis-kezelőt használ, nyissa meg egy txt-szerkesztő programmal (pl.: Windows jegyzettömb) az XML_Szetbontas.exe.config állományt, és a „bindingRedirect” XMLbög „newVersion” attribútum értékét állítsa be a kiszolgálón alkalmazott Oracle.DataAccess.dll verziójának

számát.

(Az

Oracle.DataAccess

verziójával

kapcsolatban

olvassa

el

„Az

alkalmazásszerver működése” c. fejezetet!). MSSQL adatbázis-kezelő esetén nincs szükség paraméter beállításra.

Mentse el a megszerkesztett XML_Szetbontas.exe.config állományt, és indítsa el az XML_Szetbontas.exe programot, ami a működéséhez szükséges adatbázis kapcsolati paramétereket az alkalmazásszerver konfigurációs állományából („ServerConfig.xml”) fogja felolvasni.

A folyamat indításához nyomja meg a „Start” gombot, az XML szétbontás folyamatának aktuális állását a folyamatjelzőkön láthatja. A sikeres futtatás végeredménye alább látható:

Kiadás: 2014.08.07.

Verzió: 3.10




Több intézmény esetén, az évek alatt felhalmozódott FIR válaszkonténerek, illetve terítéses konténerek az adatbázis méretét jelentősen megnövelték. Egy opcionálisan futtatható alkalmazás segítségével a válaszkonténerek és a terítéses konténerek tartalma letömöríthető – ezzel helyet takarítva meg az adatbázis-szerveren. A Neptun.NET őszi verziójával közreadott XMLZip alkalmazást futtatva tömörítheti le ezeket a konténereket. Csak a 2013 őszi Neptun verzió kihelyezése után futtatható le, amennyiben szeretné használni a tömörítést, ez esetben egyszeri futtatás szükséges, de a program többszöri futtatása nem okozhat problémát. Az alkalmazásból két x32 és az x64 verzió is készült. Az ftp-ről letöltött zip file tartalmát csomagolja ki az alkalmazásszerver könyvtárába. A zip állomány tartalma két file:  XMLZip.exe,  XMLZip.exe.config. Amennyiben Oracle adatbázis-kezelőt használ, a „BindingRedirect” XML-bögöt az XMLszétbontás config állományához hasonlóan az XMLZip.exe.config-ban is! Mentse el a megszerkesztett XMLZip.exe.config állományt, és indítsa el az XMLZip.exe programot, ami a működéséhez szükséges adatbázis kapcsolati paramétereket az alkalmazásszerver konfigurációs állományából („ServerConfig.xml”) fogja felolvasni. Amennyiben paraméter nélkül indítja az alkalmazást, csak a válaszkonténerek tömörítését végzi el az alkalmazás, amennyiben „-t” kapcsolóval futtatja, a válaszkonténerek és a terítéses konténerek tartalma is tömörítésre kerül.

A folyamat indításához nyomja meg a „Start” gombot! A Neptun kliensalkalmazás használata során a tömörített konténerek továbbra is ugyanúgy láthatóak lesznek, mint tömörítetlenül. Nagy adatbázissal rendelkező intézmények esetén a futtatás sokáig tarthat, akár néhány órába is telhet!

Kiadás: 2014.08.07.

Verzió: 3.10




6. Adatgyűjtés, statisztika, riportok 6.1. Rendszer működéséről A Neptun.NET egységes tanulmányi rendszer üzemeltetése során vannak olyan időszakok, amikor kiemelt figyelmet kell fordítanunk a szervereink működésére. A kritikusnak számító időszakokban állítsunk be olyan monitorozási funkciókat, melyekkel a rendszerünkről jellemző adatokat gyűjthetünk, és azok későbbi kiértékelésével fontos döntéseket hozhatunk. Erre megfelelő eszköz a perfmon (Performance) alkalmazás.

6.2. Adatbázis működése Az adatbázis működését a rendszer élete során célszerű több esetben is monitorozni, és a felmerülő beállításokat elvégezni. Elképzelhető, hogy egy év alatt több esetben is át kell hangolnunk az adatbázist a jobb skálázhatóság érdekében. A monitorozásra és a paraméterek módosítására használjuk az Oracle által szállított Enterprise Manager web alkalmazását.

6.3. Adatgyűjtés a Neptun működéséről A Neptun.NET egységes tanulmányi rendszer használata során felmerül az igény olyan jellegű adatok lekérdezésére, melyből a rendszer használatáról annak rendelkezésre-állásáról és kihasználtságáról kapunk információkat. Ebben a fejezetben azon lekérdezések, módszerek kerülnek

ismertetésre,

melyek

segítségével

folyamatosan

tájékozódhatunk

intézményünk

tanulmányi rendszerének metrikus adatairól.

6.3.1.1. Tárgyfelvételek száma A rendszer terheltségének egyik kritikus pontja a tárgyfelvételi időszak. A korábban ismertetett lekérdezésekkel ilyenkor is érdemes figyelni, hogy melyik szerverünkről hány felhasználó szeretne belépni. A belépések száma, és a rendszerben lévő felhasználók által folytatott tevékenységek hatékonyságának mutatója az óránkénti tárgyfelvételek száma. A következő lekérdezés használatával gyors áttekinthetést kaphatunk a tárgyfelvétel működéséről. -- Neptun.Net tárgyfelvételek száma

Kiadás: 2014.08.07.

Verzió: 3.10




select * from select to_char(il.C_SIGNINDATE,'YYYY.MM.DD HH24')||':00.000 - ' || to_char(il.C_SIGNINDATE, 'YYYY.MM.DD HH24')||':59.999' as "Időintervallum", count(*) as "Jelentkezések száma", round(count(*)/60,1) as "Tárgyfelvétel percenként" from t_indexline il where il.C_SIGNINDATE > to_date('2009.02.06 10:00','YYYY.MM.DD HH24:MI') group by to_char(il.C_SIGNINDATE,'YYYY.MM.DD HH24') order by 1) union select 'Összesen', count(*), round(count(*)/ (to_number(( sysdate-to_date( '2009.02.06 10:00', 'YYYY.MM.DD HH24:MI' ) ) * 24 * 60),1) from t_indexline il where il.C_SIGNINDATE > to_date('2009.02.06 10:00','YYYY.MM.DD HH24:MI');

)

Időintervallum Jelentkezések száma Jelentkezések percenként ------------------------------ ------------------- -----------------------2009.02.06 10:00.000 - 2009.02.06 10:59.999 9453 157,6 2009.02.06 11:00.000 - 2009.02.06 11:59.999 2228 37,1 2009.02.06 12:00.000 - 2009.02.06 12:59.999 1192 19,9 2009.02.06 13:00.000 - 2009.02.06 13:59.999 1066 17,8 2009.02.06 14:00.000 - 2009.02.06 14:59.999 1017 17,0 2009.02.06 15:00.000 - 2009.02.06 15:59.999 695 11,6 2009.02.06 16:00.000 - 2009.02.06 16:59.999 629 10,5 Összesen 16280 39,4 SQL>

A példában szereplő lekérdezés egy előre meghatározott időponttól (2009.02.06 10:00) mutatja meg a tárgyfelvételek számát a lekérdezés futatásának pillanatáig. Az első oszlop az időintervallumot – óránkénti bontás -, a második oszlopban az adott intervallumhoz tartozó tárgyfelvételek száma, míg az utolsó oszlopban a percenkénti átlag található.

6.3.1.2. Vizsgajelentkezések száma Egy másik kritikus időszak a rendszer életében a hallgatók vizsgajelentkezése. Ebben az időszakban a hallgatók által elvégzett vizsgajelentkezéseket érdemes monitorozni, a belépések, illetve az egyéb terhelési adatok mellett. Ezt az információt a következő lekérdezés alkalmazásával kaphatjuk meg, a korábbi példához hasonlóan. -- Neptun.Net vizsgajelentkezések száma select * from (select to_char(es.c_signindate,'YYYY.MM.DD HH24')||':00.000 - ' ||to_char(es.c_signindate,'YYYY.MM.DD HH24')||':59.999' as "Időintervallum", count(*) as "Jelentkezések száma", round(count(*)/60,1) as "Jelentkezések percenként" from t_examsignin es where es.c_signindate > to_date('2008.12.08 08:00','YYYY.MM.DD HH24:MI') group by to_char(es.c_signindate,'YYYY.MM.DD HH24') order by 1) union select 'Összesen',count(*), round(count(*)/

Kiadás: 2014.08.07.

Verzió: 3.10




(to_number((sysdate - to_date('2008.12.08 08:00','YYYY.MM.DD HH24:MI')))*24*60),1) from t_examsignin es where es.c_signindate > to_date('2008.12.08 08:00','YYYY.MM.DD HH24:MI'); Időintervallum Jelentkezések száma Jelentkezések percenként ----------------------------- ------------------- -----------------------2008.12.08 08:00.000 - 2008.12.06 09:59.999 5657 94,3 2008.12.08 09:00.000 - 2008.12.06 10:59.999 1211 20,2 2008.12.08 10:00.000 - 2008.12.06 11:59.999 1085 18,1 2008.12.08 11:00.000 - 2008.12.06 12:59.999 926 15,4 2008.12.08 12:00.000 - 2008.12.06 13:59.999 772 12,9 2008.12.08 13:00.000 - 2008.12.06 14:59.999 755 12,6 2008.12.08 14:00.000 - 2008.12.06 15:59.999 607 10,1 Összesen 10046 39,4

Kiadás: 2014.08.07.

Verzió: 3.10




7. Biztonságtechnikai megoldások 7.1. Adat- és információvédelem Az adatok védelme napjaink egyik legfontosabb feladata az informatikában. Rengeteg adatot továbbítunk hálózatokon keresztül, anélkül, hogy tudnánk annak útvonalát, formáját. A célunk, hogy eljusson az általunk kívánt helyre. Fontos tudni, hogy a tanulmány rendszerben tárolt adatokkal kapcsolatban nem szabad minden információvédelmi feladatot a Neptun rendszerre bízni, és annak ellenére, hogy jelentős mennyiségű fejlesztés található benne, ami az adatok megóvására irányul, ezt nem is várhatjuk el tőle. Nagyon fontos a rendszert kiszolgáló környezet.

7.2. Komplex informatikai biztonság 7.2.1. Az adatvédelem célja Az komplex informatikai biztonság lényege, a számunkra fontos és értékes adatok és információ illetéktelenek kezébe kerülésének megakadályozása. Az illetéktelen hozzáférések elsősorban az interneten keresztül történnek, ezért nyugodtan hívhatjuk hálózati biztonságnak az ezzel foglalkozó biztonsági kérdéseket, mivel az internetet egy nagy hálózatnak tekintjük. A biztonság igénye az internet terjedésével együtt nőtt, ezért a legtöbb biztonsági program, illetve intézkedés a külső és jogosulatlan hozzáférés ellen készültek. A jogosulatlan hozzáférés elkerülése végett olyan biztonsági megoldásokat kell alkalmazni, amelyek lelassítják, illetve megakadályozzák az információ kiszivárgását, illetve kikerülését a külvilágba. A biztonság több szinten is megvalósítható. A biztonsági szintek ésszerű összehangolásával, egymásra építésével, fokozhatjuk a védett információ biztonságát, elérhetetlenségét.

7.2.2. Teljes körű védelem A teljes körű védelem alatt azt értjük, hogy a Neptun rendszert olyan környezetbe kell telepíteni, mely megbízható és biztonságos önmagában is, és az adatok más módon történő hozzáférése korlátozott, valamint az adatok manipulálása külső eszközökkel nem lehetséges, és a rendszert üzemeltető személyek minden esetben tudnak döntést hozni a váratlan események elhárítására.

Kiadás: 2014.08.07.

Verzió: 3.10




7.2.3. Megoldások körei Mint már azt említettük, a Neptun.NET rendszer önmagában nem elegendő, fontos annak környezete is, ezért a megoldást 3 fő részre bonthatjuk, melyek az „Általános adatvédelmi megoldások” , „Neptun.NET által kínált szolgáltatások” és az „Adatbázis biztonsági rész”, melyek összhangban történő működtetése teszi megbízhatóvá a tanulmányi rendszert, és ezáltal tudja garantálni számunkra az adatok valódiságát.

7.3. Általános adatvédelmi megoldások Az általános adatvédelmi ajánlásainkat további 3 nagyobb csoportra bonthatjuk, melyek minden esetben az intézményi üzemeltetés feladata elvégezni. Mivel ahány ház annyi szokás, ezért erről túlságosan részletesen nem érdemes beszélni, viszont az alapvető követendő irányelveket mindenképpen fontos betartani és betartatni. Ezen feladatok minden esetben az intézmény hatáskörébe tartoznak és az ehhez kapcsolódó hibák elhárítása is.

7.3.1. Fizikai védelem Napjainkban, ha adatvesztésről, vagy adatlopásról hallunk, akkor ritkán gondolunk arra, hogy bármilyen fizikai esemény áll a történések mögött, mégis nagyon fontos a szervereink biztonságos helyen tárolása. A szervertermekkel, szerverszobákkal kapcsolatos fő elvárások :  A szerverek tovább működése a biztonságos leállásig áramkimaradás esetén is biztosított legyen (redundáns és szünetmentes tápegységek) ,  A szerver számítógépek tűz, víz, elemi kár és betöréses lopás elleni biztosításának megoldása,  Megfelelően klimatizált helyiség,  Megbízható személyek alkalmazása, bizalmi munkakör,  A szerver számítógépek környezetében elfogadható szintű fizikai védelemnek kell biztosítania azt, hogy a számítógéphez illetéktelen személyek fizikailag ne férjenek hozzá,  A szerverszobába történő belépések naplózása (beléptető rendszer).

Kiadás: 2014.08.07.

Verzió: 3.10




7.3.2. Hardveres védelem Fontos, hogy a szervereinkhez érkező kéréseket megfelelő eszközökkel szűrjük, ami a legkisebb sebességvesztés mellett, nagy és jól konfigurálható biztonsági kapuként működik.  Hardveres tűzfal használata, mely megvizsgálja a hálózatba lépő adatokat, és csak akkor engedik át őket, ha megfelelnek bizonyos feltételeknek,  A hálózatokhoz a hardveres tűzfalak a legjobbak, mivel a hálózat összes számítógépét védik,  Egy további védelmi réteget is nyújtanak azzal, hogy a hálózati számítógépeket láthatatlanná teszik kívülállók számára.

7.3.3. Szoftveres védelem Az általános biztonságtechnikai megoldások körét a szoftveres védelmi beállítások zárják.  Házirend készítése,  Rendszergazda felhasználó, és rendszergazdai szerepkör korlátozott kiadása,  Az adott felhasználónak mindig csak a rábízott feladathoz legyen jogosultsága,  Megfelelően bonyolult jelszavak választása, generálása illetve azok érvényességének szabályozása,  A sikeres és sikertelen belépések naplózása . Léteznek kifinomultabb hitelesítési rendszerek (például intelligens kártyák, ujjlenyomat- vagy íriszvizsgálat). A jelszavak a legelterjedtebbek, mivel egyszerűen használhatók. Ez viszont azzal jár, hogy egyszerűen fel is törhetők. A hackerek automatikus eszközeikkel percek alatt megtalálják az egyszerűbb jelszavakat, vagy kicsalhatják az alkalmazottaktól.

7.3.3.1. Megfelelő lépések és kockázatbecslés  Jogosultságok beállítása (lehetőleg csoportok és nem felhasználók szintjén),  Védelmi eszközök karbantartása,  Házirendek létrehozása és ellenőrzése, a felhasználók oktatása,  Forgatókönyvek készítése vész- illetve katasztrófahelyzetekre,  Programok frissítése,

Kiadás: 2014.08.07.

Verzió: 3.10




 A gyártók gyakran adnak ki frissítéseket és hibajavításokat programjaikhoz, melyek befoltozzák a felfedezett biztonsági réseket,  Felhasználók jelszavainak védelme,  Ismételt, folyamatos próbálkozások elleni védelem,  Néhány hibás próbálkozás után a próbálkozó kizárása egy meghatározott időre,  Helytelen próbálkozások közti várakozási idő folyamatos növelése,  A rendszer nem árulja el, hogy a felhasználó név érvénytelen-e vagy a jelszó hibás,  Fontos a felhasználók képzése.

7.4. Neptun.NET rendszer biztonsági megoldások A Neptun.NET 3 rétegű architektúrájának ismerete segít abban, hogy átlássuk miért is fontos a Neptun.NET rendszert körülvevő környezet, erről már részletesen írtunk az 1.1-es fejezetben.

7.4.1. Adattitkosítás az alkalmazás és adatbázis szerverek között Mivel ezek a beállítások plusz terhelést jelentenek, így nem szoktuk alkalmazni, ezért ebben a dokumentációban ezek beállítására részletesen nem térünk ki. Az Oracle lehetőséget nyújt egy titkosított csatorna kialakítására melyhez TCPS protokoll használata SSL (Secure Socket Layer) ajánlott. Az MSSQL is kínál erre megoldást, melyet a kapcsolatleíróban lehet beállítani az (encrypted = yes;) kapcsoló használatával.

7.4.2. Alkalmazásszerver és kliens közötti biztonságtechnikai lehetőségek A Neptun.NET integrált titkosításának fő jellemzői:  Változó kulcshosszúság titkosítás,  Gyorsaság, nem befolyásolja jelentősen a kommunikáció sebességét,  Megbízhatóság, a kulcs ismerete nélkül nem lehet visszafejteni,  Tömörség, nem növeli az információ méretét jelentősen,

Kiadás: 2014.08.07.

Verzió: 3.10




A Neptun.NET a Blowfish metódust használja, ami változó kulcshosszúság (maximum 448 bites kulcsokkal képes kódolni), blokk-kódolással (64 bites blokkokat titkosít) rendelkezik és működése a kulcs kiterjesztési fázisával előállít egy tömböt (kulcstömb előállítása) és a titkosítás a kulcstömb alapján kerül végrehajtásra.

7.4.3. Neptun.NET web kliensek adatforgalmának védelme A felhasználók bárhol lehetnek a világban, a klienssel ellentétben ez egy nem megbízható környezet, ezért a WEB szerverek védelmére kiemelt figyelmet kell fordítani. A jó megoldás a titkosított csatorna használata (HTTPS). Beállításával részletesen a telepítési fejezet foglalkozik. További lehetőség, ami mind az alkalmazásszerver mind a web szervereken alkalmazható, hogy a konfigurációs fájl segítségével IP tartományos szűrést van módunk megvalósítani. Egy biztonsági rés lehet, ha a rendszerben küldött üzenetbe linket ágyaznak. Ennek védelme az IIS helyes beállításával érhető el. Az AntiXSS-nek „FullTrusted” módra kell állítani.

7.4.3.1. Webreugrás webservice biztonsági lehetőségek A Neptun.Net Egységes tanulmányi rendszer, lehetőséget biztosít az adminisztrátoroknak, hogy a kliensben kiválasztott hallgató adatait a webes felületen is elérjék. Ehhez a funkcióhoz az úgynevezett „webreugrás” műveletet alkalmazza a rendszer mely a web-szerveren futó webszolgáltatáshoz (service.asmx) kapcsolódik. Ezt a szolgáltatás célszerűen csak azokról a gépekről, tartományokból engedélyezzük, ahol azok a kliensek futnak, melyekről ez a szolgáltatás is engedélyezett. Mivel ez magas jogosultságú szerepkörhöz kötött, így ez valószínűleg csak kevés felhasználót és helyet érinthet. A lehetséges támadási pontok csökkentése érdekében az alábbi beállítások alkalmazását javasoljuk. A legfontosabb biztonsági lehetőség: az IIS-en belül „File and directory security” beállítással, a lehető legszűkebb IP tartománynak megengedni a file hozzáférést a service.asmx állományon. Lehetőség van AD esetén egyedi felhasználói jogosultságra is,ez IIS verzió függő. További lehetőségként, a web.config állomány alábbi kapcsolóival lehet minimalizálni a biztonsági rést:

Kiadás: 2014.08.07.

Verzió: 3.10




A web.config állományban a következő tag-ek elhelyezésével, illetve eltávolításával lehet szabályozni a hozzáféréseket. Az „” kifejezéssel bekapcsolni, míg a „” kifejezéssel kikapcsolni lehet az egyes szolgáltatásokat. Az alábbi részlet egy példa a beállításra: <webServices> <protocols>

Az egyes szolgáltatások jelentése az alábbiakban olvasható: HttpPost/HttpGet – standard post/get metódusokkal lehet hívni a webszervízt, ha nem engedélyezett, akkor csak soap. PHP/JavaScript/etc hívások esetén szokták engedélyezni, ha az intézmény egyedi célra is használja. HttpPostLocalHost – a hívást engedélyezi, de csak localhost-ról, a fogadáshoz kell a HttpGet. Documentation - böngészőből olvasható szerviz dokumentáció, a hívási metódusok és azok paramétereinek pontos leírása. Ha a webre ugrásnál a következő hiba jön: „Az ügyfél-hitelesítés befejezéséhez tanúsítvány szükséges”, akkor meg kell vizsgálni, hogy a web szerver gépen nem csak a webhez rendelt tanúsítványok legyenek benne a megbízható tanúsítványok között, hanem a gyökér tanúsítványok közül az összes is.

7.4.4. Jogosultság és szerepkör A Neptun.NET kiterjedt jogosultsági és szerepkör rendszerrel rendelkezik. Fontos, hogy a szerepköröket úgy készítsük el, hogy a felhasználókat jól tudjuk csoportosítani a tevékenységi körüknek megfelelően így a szerepkörökhöz rendelt funkciók és adatokhoz lesz csak hozzáférése egy adott felhasználónak.

Kiadás: 2014.08.07.

Verzió: 3.10




7.4.5. Használjon erős jelszavakat A legtöbb intézmény jelszóval azonosítja a felhasználókat. Léteznek kifinomultabb hitelesítési rendszerek (például intelligens kártyák, ujjlenyomat- vagy íriszvizsgálat). A jelszavak a legelterjedtebbek, mivel egyszerűen használhatók. Ez viszont azzal jár, hogy egyszerűen fel is törhetők. A hackerek automatikus eszközeikkel percek alatt megtalálják az egyszerűbb jelszavakat, vagy kicsalhatják az alkalmazottaktól. Gyakran előfordul az is, hogy a jelszavak nem megfelelőek a következők miatt:  A jelszavak túl egyszerűek, vagy soha nem változtatják meg őket,  A jelszavak jól láthatóan le vannak írva a számítógép mellett,  A jelszavak által nyújtott védelem akkor használható igazán, ha az alkalmazottak tudják, hogy miért fontosak a jelszavak. Úgy kell kezelni a jelszavakat, mint egy fontos irodakulcsot: nem szabad odaadni másoknak. Kerüljék a gyenge, egyszerűen kitalálható jelszavakat, például:  Igazi nevek, felhasználónevek és cégnév,  Szokásos, a szótárban is megtalálható szó, ami „szótáras támadással" könnyen feltörhető,  Szokásos jelszavak, mint például „jelszó", „engedjbe" vagy „1,2,3,4",  Általánosan elterjedt betűhelyettesítők, mint például „!" az "i" betű helyett, vagy „$" az „s" betű helyett,  Olyan jelszó, amit valaki más ismer. Milyen egy „erős" jelszó? A következő jellemzőkkel kell rendelkeznie:  Legalább nyolc karakter hosszú, minél hosszabb, annál jobb.  Kis- és nagybetűket, számokat és jeleket is tartalmaz.  Legfeljebb 90 naponta változik, és minden alkalommal teljesen más, mint a korábbi.

7.4.6. Jelszavak tárolása Az md5 egy hash függvény. A hash amolyan gyűjtőnév, hasító függvénynek vagy tördelőfüggvénynek is szokták mondani. A lényeg, hogy a bemenetet mindig egy fix hosszúságú kimenetre képezi le, md5 esetén 128 bit, és úgy, hogy visszafele ne működjön az algoritmus,azaz nem lehet visszafejteni. Vannak más hash függvények is, pl sha1.

Kiadás: 2014.08.07.

Verzió: 3.10




Jelszó "tárolásra" ez önmagában viszont nem jó megoldás. Az igaz, hogy nem lehet visszafejteni, de nem is akarjuk. Inkább fogunk egy szótárat, leképezzük az összes elemének a hash kimenetét, és összehasonlítjuk a "tárolt" jelszó hash-ével, és máris tudjuk mi volt a jelszó. Ennek a kivédésére egy jó megoldás az úgynevezett sózás. Arról van szó, hogy a hash amit tárolunk nem a jelszó hash-e, hanem a jelszó hash és egy véletlen kiválasztott karaktersorozat hash egy részének konkatenálásból előállított karaktersorozat.

7.4.7. Jelszó szabályok Bevezetésre került a jelszó szabályok kialakításának lehetősége a Neptun.NET rendszerekben. Minden jelszószabály az alábbi elemekből épülhet fel:  név;  elévülés (azaz egy adott jelszó hány nap múlva jár le, utána kötelező jelszót cserélni) – „0” esetén nem aktív;  utolsó X darab kitiltása (azaz visszamenőleg ennyi régi jelszó nem használható fel újként) – „0” esetén nem aktív;  utolsó X nap kitiltása (azaz visszamenőleg ennyi napja előfordult jelszavak nem használhatóak fel újként) – „0” esetén nem aktív;  bonyolultsági szabály (5db); reguláris kifejezéssel megadott szöveges szabály a jelszó bonyolultságára tekintve;  üres esetén nem aktív reguláris kifejezéseknél találatot keres, nem teljes egyezőséget (ugyanis ez megadható regex kifejezéssel, ha szükséges). Minden felhasználó tetszőleges számú egyéncsoport tagja lehet, és minden egyéncsoporthoz tartozhat legfeljebb egy jelszószabály sor. Szabályok kiértékelése belépéskor, ha az adatbázis mező szerint a jelszóváltoztatás kötelező, akkor kötelező, az adott felhasználó összes csoportjához tartozó elévülési szabály nem determinisztikus sorrendben kiértékelődik, és ha valamelyik szerint lejárt, akkor a jelszóváltoztatás kötelező egyébként pedig nem kell jelszót cserélni. Saját jelszó változtatásakor az adott felhasználó összes egyéncsoportjához tartozó bonyolultsági szabály nem determinisztikus sorrendben kiértékelődik, illetve ha valamelyik szerint a jelszó nem megfelelő akkor visszadobja azt. Amennyiben az utolsó jelszavak ellenőrzése közül egy is aktív akkor az éppen aktuális jelszót nem engedi visszaírni. A reguláris kifejezésekre csak teljesülés és nem teljes egyezőség vizsgálat van. Ha valamelyik kifejezés hibás, teljesültnek tekinti.

Kiadás: 2014.08.07.

Verzió: 3.10




Az adminisztrátor által más felhasználó jelszavának változtatásakor a jelszó bonyolultsági ellenőrzés nem történik meg! A jelszószabályokat a szerver gyorsítótárazza, a módosításokat az aktuális szerveren azonnal, a többi legkésőbb a beállított frissítési időn belül (5perc alapértelmezetten) észleli. Jelszóváltoztatáskor (akár saját akár adminisztrátori) tárolódik a régi jelszó, így az újrafelhasználhatóság ettől a pillanattól számítódik. Ellentmondásos szabályok esetén (pl. egyik csupa kisbetű, a másik csupa nagybetű) a szerver döntésképtelen a jelszóváltoztatás nem lehetséges, ezek felderítése és javítása adminisztrátori hatáskör. A jelszószabályok létrehozásához, a szabványos REGEX kifejezések használhatók. Az alábbi táblázat néhány példát mutat be az alkalmazásukra. Illesztés egy karakterre (karakterosztályok) .

mindenre illeszkedik (kivéve az újsort: \n, ld. s opció).

[abcde]

minden felsorolt karakterre illeszkedik (karakterosztály) minden karakterre illeszkedik, kivéve a ˆ után felsoroltakat (negált

[ˆabcde]

karakterosztály)

[0-9a-fA-F]

(-) tartományokat jelöl ki (kivéve az elso és utolsó helyen) egy szókarakterre illeszkedik (alapesetben [a-zA-Z_0-9], de nemzeti

\w

beállítás is lehetséges).

\W

szókarakterre nem illeszkedik

\s

bármilyen „üres” (whitespace) karakter (szóköz, tabulátor, újsor. . . )

\S

nem üres karakter

\d

digitális számjegy ([0-9])

\D

nem digitális számjegy

Mennyiségjelzok (kvantorok) *

0 vagy több illeszkedés (vele ekvivalens {0,})

+

1 vagy több illeszkedés (vele ekvivalens {1,})

?

1 vagy illeszkedés (vele ekvivalens {0,1})

{n}

n illeszkedés

{n,}

legalább n illeszkedés

{n,m}

legalább n, legföljebb m illeszkedés

Választó mintaillesztés (alternation) a függőleges vonallal („pipe”) elválasztottak egyike

|

Kiadás: 2014.08.07.

Verzió: 3.10




(?(részkifejezés)igen|ne ha a részkifejezés illeszkedik, az igen részre, egyébként a nem részre

m) Példák: [A-Za-z_][A-Za-z0-9_.-

Szabványos felhasználói név, ami betűvel számmal vagy aláhúzással

]*

kezdődik és betűvel számmal aláhúzással ponttal kötőjellel folytatódhat

.{5,10}

Legalább 5 legfeljebb 10 bármilyen karakterre illeszkedik

[\w]{6,}

legalább 6 darab szó karakterre illeszkedik

7.5. Neptun.NET rendszer beléptetési metódusai A Neptun.NET rendszer több beléptetési, azaz felhasználó-azonosítási metódussal rendelkezik. Ezeket a metódusokat az alábbi pontokban tárgyaljuk.

7.5.1. Hagyományos jelszavas autentikáció A hagyományos felhasználónév-jelszó páros megadás egyszerű és közkedvelt megoldás, mert nem jelent plusz kiadást az intézményeknek, mégis megfelelő biztonságot nyújt adataink védelmére. A jelszavak az adatbázisban titkosítva kerülnek tárolásra, azok visszafejtése nem lehetséges. Ha valaki elfelejtette a jelszavát, úgy nincs lehetőség annak visszakeresésére, ebben az esetben az adminisztrátor tudja megváltoztatni.

7.5.2. Központi autentikáció használatával Felhasználók egységes kezelése más rendszerekkel. A filozófia alapja: „egy név - egy jelszó”. A felhasználóknak így nem szükséges minden egyetemi rendszerben egy-egy generált azonosítót kérniük és megjegyezniük, hanem csak egy, általuk választott név/jelszó páros segítségével férhetnek hozzá a szolgáltatásokhoz. A rendszer alapja egy OpenLDAP adatbázis, amelybe bárki regisztrálhat a Netpun-kódjával azonosítva magát.  Akár kétirányú szinkronizáció,  Központi adminisztrátori felület,

Kiadás: 2014.08.07.

Verzió: 3.10




 Az alkalmazás szerver és AD között lehet titkosított kapcsolatot is beállítani,  Szinkronizáló fájl készítés,  LDAP beállítása SDA.ConfigEditor segítségével,  Ellenőrzi hogy elérhető-e az AD,  Ellenőrzi, hogy létezik-e a felhasználó a Neptun adatbázisában,  Lekérdezi az AD-ból hogy az adott felhasználó és jelszó páros létezik-e,  Létezik más típusú együttműködés is LDAP rendszerrel, adott táblákba nézetekbe gyűjtünk változási információkat,  Szinkronizáló fájl készítése: Aduserimpoerter.exe (ad -ba).

7.6. Konfigurációs állományok védelme Kliens oldalon az alkalmazás szerverek IP azonosítója nem látható. A ServerConfig.XML titkosításával garantáljuk, hogy az adatbázis jelszava, és egyéb intézmény specifikus beállítások nem láthatók.

7.7. Reaktív és proaktív tevékenységek Fontos megemlíteni, hogy a rendszer folyamatos működésének érdekében bevezettünk egy központi szerveres rendszert, mely folyamatosan kommunikál az intézmény alkalmazásszerverekkel. A rendszerhibák központi szerverre továbbításával lehetőség van arra, hogy a fejlesztőkhöz és üzemeltetőkhöz a lehető legrövidebb időn belül eljussanak a kritikus hibák. Ettől függetlenül használjunk monitoring lekérdezéseket akár ad-hoc, akár ütemezett jelleggel, amely segítségével információkat gyűjthetünk a rendszerünk működéséről és a használat során fellépő magas terhelésekről. Ilyen adatok lehetnek a táblatéren belüli lemezterület vagy magas sessionszám. Lehetőség van az adatbázis kezelő rendszerben is értesítési beállításokra, mely a riasztásokat továbbítja a megadott személyeknek. Ezek megfelelő konfigurációja esetén elkerülhetőek az üzemeltetés oldali leállások.

7.8. Adatbázisszerver védelme

Kiadás: 2014.08.07.

Verzió: 3.10




Az adatbázisszerver a legfontosabb pontja a rendszernek, mivel minden adatunkat azon tároljuk, ezért annak védelmére kiemelt hangsúlyt kell fektetni. Nagyon fontos, hogy gondoskodjunk a mentésekről, és a szerver megfelelő időszakonkénti karbantartásáról. Készítsünk mentési terveket és szervezzük meg az adatbázis felügyeletét. A katasztrófaterv elkészítéséhez támpontokat kapunk az üzemeltetési fejezetben.

7.9. Felhasználók képzése A felhasználók az egyik leggyengébb láncszeme az informatikai biztonságnak. Sajnos sok példa van arra, hogy nem tudnak biztonságos jelszavakat kitalálni, ha mégis, akkor egy cetlin felragasztják őket a monitorra, vagy első szóra elárulják őket másnak. Régi, elavult biztonsági szoftvereket használnak, minden beérkező levelet megnyitnak, minden linkre rákattintanak, a "phising" jelenséget pedig még csak hírből sem ismerik. Ha valami balul sül el, rémülten hívják a rendszergazdát. Véleményünk szerint a megoldás a felhasználók továbbképzése lenne.

Kiadás: 2014.08.07.

Verzió: 3.10




8. Együttműködés a Poszeidon rendszerrel 8.1. Együttműködés fogalma Együttműködésről akkor beszélünk amikor a Poszeidon rendszer a Neptun adatbázisában tárolt partnertörzsre épít. Az együttműködés során egy olyan közös adathalmaz kerül kialakításra, melyben mindekét rendszer azonos jogosultsággal rendelkezik. Ez a halmaz főként adattáblákban valósul meg.

8.2. Adatbázis kialakítása Az együttműködő rendszerek kialakítása során, a Neptun adatbázisában nem kell szerkezeti módosítást végrehajtani, viszont az érintett táblákra a megfelelő jogosultságok kiadása szükséges. A szerkezeti módosításokat a Poszeidon sémájában kell elvégezni, mely a közös táblák eldobásából és azok helyére a Neptun sémára mutató szinonimák létrehozásából áll, valamint a kapcsolódó kényszerek átirányításából. A scripteket egy adott verzióhoz kell generálni és azokban POSZEIDON és NEPTUN3R felhasználókra épít, amennyiben ez az intézménynél eltérő úgy a scripteket módosítani szükséges. A létrehozás extra terheléssel nem jár, a Neptun rendszer működését nem befolyásolja. A scriptek futatásához egy DBA jogosultságú (szerepkörű) felhasználóra van szükség. Végrehajtási lépések: 1. Poszeidon táblaterek és felhasználók létrehozása (Create_Win_Standard_Poszeidon_Test.sql) 2. Poszeidon referencia séma betöltése (export fájlból) 3. Poszedionban lévő közös táblákra mutató kényszerek eldobása (drop_pos_fk.sql) 4. Poszedionban lévő közös táblák eldobása (drop_pos_tables.sql) 5. Szinonimák létrehozása (create_synonym_pos_for_n3r.sql) 6. Írási olvasási jogok megadása poszeidon számára (grant_sel_ins_upd_del_pos_for_n3r.sql) 7. Refernecia jogok megadása poszeidon számára (grant_references_pos_for_n3r.sql) 8. Kényszerek létrehozása neptun és poszeidon között (create_fk_pos_for_n3r.sql)

Kiadás: 2014.08.07.

Verzió: 3.10




8.2.1. Együttműködési sémanév beállítása A verziófrissítések során előfordulhat, hogy olyan objektumok keletkeznek, módosulnak, melyeket mindkét rendszer közösen használ. Mivel a verziófrissítő scriptek egységesek ezért azokban, nem lehet előre definiálni, hogy melyik intézmény hogyan nevezte el a két rendszer adatbázisát. Ahhoz, hogy az ilyen közös objektumok továbbra is problémamentesen működjenek mindkét rendszerben, egy-egy rendszerparaméter segítségével be kell állítani, hogy az adott Neptun rendszerhez melyik nevű Poszeidon adatbázis tartozik, illetve fordítva, hogy az adott Poszeidon rendszerhez melyik nevű Poszeidon adatbázis tartozik.  Neptunban:

„POSZEIDON_SCHEMA_NAME” – Poszeidon adatbázis felhasználóneve

 Poszeidonban: „NEPTUN_SCHEMA_NAME” – Neptun adatbázis felhasználóneve

8.3. Verzió kompatibilitás A Poszeidon és Neptun közös használata során fontos kiemelni, hogy be kell tartani a verzió kompatibilitási szabályt, ami megadja, hogy egy megadott verziójú Neptun milyen verziójú Poszeidon rendszerrel képes együttműködni. A kompatibilitásról a verzió kiadásakor kap tájékoztatást az intézmény. Amennyiben egy Neptun verziófrissítés nem érinti a partnertörzs objektumait, úgy lehetséges a Neptun rendszer frissítése a Poszeidon rendszertől függetlenül. Ez az állítás fordítva is igaz, azaz ha egy Poszeidon verziófrissítés nem növeli a közös rész verziószámát, úgy lehetséges az önálló Poszeidon frissítés. Ez azt jelenti, hogy ilyen frissítés esetén nem szükséges a másik rendszer leállítása, de ajánlott. Amennyiben egy verziófrissítés során az intézmény azt a jelezést kapja, hogy a frissítés módosítja a közös táblákat, úgy a két rendszer csak együtt frissíthető. A frissítés során minden esetben a Neptun rendszert kell először frissíteni, majd a sikeres frissítés után lehet elvégezni a Poszeidon rendszer frissítését. A sorrend betartása fontos, mert a Poszeidon frissítési eljárása már építhet a közös rész módosításaira.

Kiadás: 2014.08.07.

Verzió: 3.10




8.4. Tesztrendszer frissítése A tesztrendszerek frissítése során a két rendszert csak közösen lehet frissíteni, mert a két rendszer közös szekvenciát használ, valamint a két séma között kereszthivatkozások találhatók, melyek a külön-külön áttöltés esetén inkonzisztens állapotot eredményezhet. Az áttöltés a Neptun részben leírtaknak megfelelően történik azzal a kivétellel, hogy a mindkét sémát egyszerre kell ki exportálni illetve beimportálni. Példa az exportra (a szögletes zárójelben lévő értékek behelyettesítendőek): C:\expdp.exe [user]/******@[alias] SCHEMAS = [neptun3r],[poszeidon] DUMPFILE = neptun3r_poszeidon_export.dpe LOGFILE = neptun3r_poszeidon_export.log DIRECTORY = BACKUP_DIR ESTIMATE = STATISTICS

Példa az importra (a szögletes zárójelben lévő értékek behelyettesítendőek): C:\impdp.exe [user]/******@[alias] SCHEMAS = [neptun3r],[poszeidon] DIRECTORY = BACKUP_DIR DUMPFILE = neptun3r_poszeidon _export.dpe LOGFILE = neptun3r_poszeidon _import.log REMAP_SCHEMA = [neptun3r]:[neptun3r_test],[poszeidon]:[ poszeidon _test] REMAP_TABLESPACE = [neptun_dat]:[neptun_test_dat],[poszeidon_dat]:[poszeidon _test_dat] TABLE_EXISTS_ACTION = REPLACE

Kiadás: 2014.08.07.

Verzió: 3.10




9. Szószedet Neptun.NET A Neptun Egységes Tanulmányi rendszer második generációs, 3 rétegű architektúrára felépített változata. Másik elterjedt neve a „Neptun3R”. Release Release -nek nevezzük azt a programverziót, ami sikeresen átmegy a tesztelési folyamatokon, és abból egységes frissítőcsomag készül. RAID Redundáns lemezkezelés, ismertebb nevén RAID (Redundant Array of Independent Disks). A RAID megoldás nyújt a szerveren bekövetkező merevlemez meghibásodása esetben. A RAID különböző konfigurációkban megoldást kínál, hogy egy, vagy több lemez kiesése esetén is működőképes maradjon a rendszer. RAID 0 Ez a szint az adathozzáférés sebességét javítja azáltal, hogy a fájlok blokkjait egynél több lemezre osztja szét. Szigorú értelemben ez nem igazi RAID, hiszen nem redundáns, nem biztosít adatvédelmet, de a RAID 0 név rajtaragadt az ilyen rendszereken. A RAID 0 konfiguráció arra használható, hogy több független lemezt úgy fűzzünk össze, hogy azok a végén az operációs rendszer számára egy logikai lemezként látszódjanak.. A teljesítmény igen látványos, de akármelyik merevlemez meghibásodik, a teljes RAID - rendszer tönkremegy és elvesznek az adatok. RAID 1 Ez a szint megfelelő biztonságot kínál, ugyanis az adatok egy az egyben még egy merevlemezre átmásolódnak. A megoldás másik neve a merevlemez tükrözése. Ha a lemez megsérül, a másik meghajtón még mindig rendelkezésre állnak az adatok. Addig, amíg a legutolsó lemez is el nem romlik, az adatok biztonságban vannak. Az írási teljesítmény egy kicsit leromlik a másolás során az egyetlen lemezes eléréshez képest (10-20 százalékkal lassúbb), de az olvasási teljesítmény lényegesen jobb bármelyik fizikai merevlemezhez képest, hiszen a megkettőzött adatok párhuzamosan kiolvashatók. Durva közelítésként úgy lehet tekinteni, hogy a RAID 1 közel kétszeres olvasási sebességet biztosít a külön merevlemezekhez képest, és majdnem ugyanazt az írási teljesítményt.

Kiadás: 2014.08.07.

Verzió: 3.10




RAID 10 A RAID 10 a RAID 0 és 1 ötvözése, oly módon, hogy a RAID 0 által létrehozott logikai meghajtókat tükrözéssel teszi redundáns állományrendszerré. A RAID 10 másik nevén RAID 0+1 ötvözi a két különböző rendszert ezáltal a tükrözésnél elveszett írási teljesítményt, visszanyeri a több lemezre történő párhuzamos használattal az olvasási teljesítmény pedig tovább növekedik. A RAID 10 optimális tranzakció alapú adatbázis-kezelő rendszerek adatállományainak tárolására. RAID 5 A használható merevlemez-terület az összes lemezek száma, mínusz egy. Az adatok a RAID 0-hoz hasonlóan el vannak osztva a merevlemezek között. Az egyik partíción paritásblokkok készülnek az adatok

védelme

érdekében.

Egymással

XOR-kapcsolatban

vannak,

vagyis

a

rendszer

meghibásodása esetén a megfelelő paritásblokk alapján helyreállíthatók a kiesett adatok. RAID 5 használata esetén viszont éppen ezért egyszerre egynél több merevlemeznek nem szabad meghibásodnia. Ha az egyik lemez elromlik, a lehető leggyorsabban ki kell cserélni az adatvesztés elkerülése érdekében. Táblaterek (Tablespaces) Az Oracle adatbázis adatai táblaterekben tárolódnak. Az Oracle adatbázist kisebb logikai egységekre, táblaterekre oszthatjuk. A táblatér csak egy adatbázishoz tartozhat egy időben és minden táblatér egy vagy több operációs rendszerbeli állományból áll, ezek az adatállományok. A táblaterek egy vagy több szegmenst tárolhatnak. A táblatereket be- és kikapcsolhatjuk az adatbázis futása idején. A SYSTEM táblatér vagy az aktív visszaállítási szegmenst tartalmazó táblatér kivételével, a táblatereket kikapcsolhatjuk az adatbázis futása során. A táblaterek lehetnek írhatóolvasható vagy csak-olvasható állapotban. Adatállományok (Data Files) Az Oracle adatbázisban minden táblatér egy vagy több adatállományból áll. Az adatállományok alkotják az adatbázis fizikai szerkezetét, ami illeszkedik ahhoz az operációs rendszerhez, amelyen az Oracle szerver fut. Egy adatállomány csak egy táblatérhez tartozhat. Az Oracle szerver létrehozza a táblatérhez tartozó adatállományt, a megadott méretűnél egy kicsivel nagyobb területet lefoglalva a lemezen (a plusz hely a fejléc információnak kell). Az adatbázis-adminisztrátor módosíthatja az adatállományok méretét a létrehozás után is, vagy megadhatja, hogy az adatállomány dinamikusan növekedjen, ahogy az objektumok nőnek a táblatérben.

Kiadás: 2014.08.07.

Verzió: 3.10




Szegmensek (Segments) A szegmens egy megadott típusú logikai tárolási szerkezethez lefoglalt terület a táblatéren belül. Például a táblához lefoglalt terület egésze egy szegmenst alkot. A táblatér egy vagy több szegmensből áll. A szegmens nem tárolódhat több táblatérben, de több, ugyanahhoz a táblaterhez tartozó, adatállományban is elhelyezkedhet. Minden szegmens egy vagy több kiterjesztésből áll. Kiterjesztések (Extents) A szegmens helyfoglalása kiterjesztésenként történik. Minden szegmenstípus egy vagy több kiterjesztésből épül fel. Amikor a szegmenst létrehozzuk, akkor legalább egy kiterjesztést lefoglal, ahogy a szegmens növekszik, újabb kiterjesztésekkel bővül. Az adatbázis-adminisztrátor manuálisan is felvehet újabb kiterjesztéseket a szegmenshez. Egy kiterjesztés folytonos Oracle blokkok halmaza és egy kiterjesztés csak egy adatállományban helyezkedhet el. Adatblokkok (Data Blocks) A. Oracle szerver az adatállományokban a tarolási helyet Oracle blokknak vagy adatblokknak nevezett egységekben kezeli. A legalacsonyabb szinten az Oracle adatbázis adatai adatblokkokban tarolódnak. Az Oracle adatblokk a tarolás legkisebb egysége, amit az Oracle szerver lefoglalhat, olvashat vagy írhat. Egy Oracle adatblokk egy vagy több operációs rendszerblokkból áll, amit egy már meglevő fizikai állományban foglal le. A szabványos adatblokk méretét az adatbázis létrehozásakor a DB_BLOCK_SIZE inicializációs paraméterrel definiáljuk. Az adatblokk mérete legyen az operációs rendszer szintű blokk többszöröse, hogy elkerüljük a szükségtelen input-output műveleteket. Az adatblokk maximális mérete az operációs rendszertől függ. Helyileg-karbantartott táblaterek (Locally Managed Tablespaces) Ha a táblatér kiterjesztéseinek kezeléséhez bittérképet használ, akkor minden adatállományban nyilvántartja az adott állománybeli szabad és foglalt kiterjesztéseket. A bittérkép minden bitje egy blokkhoz vagy blokkok csoportjához tartozik. Amikor egy kiterjesztést lefoglalunk vagy felszabadítunk, akkor az Oracle szerver módosítja a bittérképet, hogy a megfelelő állapotot mutassa. Ez az alapértelmezés szerinti helykezelési mód a táblaterekben. Adatszótár-karbantartott táblatér (Dictionary-Managed Tablespaces)

Kiadás: 2014.08.07.

Verzió: 3.10




Ha a táblatér kiterjesztéseinek kezeléséhez az adatszótárt használjuk, akkor az Oracle szerver az adatszótár megfelelő tábláját módosítja, ha egy kiterjesztést lefoglalunk vagy felszabadítunk. Az Oracle 8.0 és a korábbi verziókban csak ez az egy módszer létezett. LOB LOB (Large Object Binary) Nagy bináris objektum, maximális mérete (4 gigabytes - 1) * (adatbázis blokk méret). Verzióscript Olyan SQL script, ami az adatbázisban történt formai (DDL) és tartalmi (DML) változásokat tartalmazza.

Segítségével

a

rendszer

adatbázisa

felkészíthető

az

újabb

programverzió

kiszolgálására.

Kiadás: 2014.08.07.

Verzió: 3.10


NEPTUN.NET ÜZEMELTETÉS

Recommend Documents