NEPTUN.NET ÜZEMELTETÉS

Átírás

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

2 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ó Dátum Változás Pont Cím Oldal * 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 112 Kiadás: Verzió: 3.10 Oldalszám: 2 / 231

3 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 152 Kiadás: Verzió: 3.10 Oldalszám: 3 / 231

4 Tartalomjegyzék 1. A Neptun.NET rendszer felépítése Hálózati architektúra Adatbázis jellemzők Az alkalmazás szerver működése Kliens működése Kliens indítás és frissítés FIR kliens oldali komponenseinek telepítése A webalkalmazás működése Telepítési információk Adatbázis telepítése Oracle Database 11g R Az Oracle rendszer telepítése Listener telepítés Adatbázispéldány létrehozása Táblaterek kialakítása Oracle adatbázis-kezelő rendszeren Adatfájlok kialakítása a táblaterekhez Sémák kialakítása Egyedi PROFILE alkalmazás Adatbázis létrehozása template segítségével Microsoft SQL Server Login létrehozása a Neptun3R tanulmányi rendszer adatbázisához Adatbázis létrehozása a Neptun3R tanulmányi rendszer adatai számára Alkalmazás szerver telepítése Előfeltételek Oracle kliens telepítése: Nem managelt DataAccess Managelt DataAccess Az Oracle DataProvider regisztrálása, újraregisztrálása GAC-ba Könyvtárszerkezet Nevesített Windows Service telepítése Konfigurációs állományok beállítása AD autentikáció Alkalmazás szerver indítása FIR beüzemelése IBM MQ kliens telepítése A Neptun.NET Windows service futtató felhasználó beállítása A FIR kulcsok beállítása Alkalmazás szerver működése Alkalmazás szerver parancsai Üzenetküldés beállításai és működése LMS telepítése Fájlok másolása Application pool létrehozása Virtuális mappák létrehozása Web.config beállítások Kiadás: Verzió: 3.10 Oldalszám: 4 / 231

5 LDAP szervizek telepítési dokumentációja Szoftver követelmény Beállítások IIS 7.x alatt Web.config beállítások Neptun DLL igények Szervizek aktualizálása A szervizek szolgáltatásairól Filetárolók beállításai Neptun MeetStreet (közösségi tér) beállítása WEB alkalmazás Könyvtár szerkezet Konfigurációs állományok beállítása Az IIS webkiszolgáló telepítése NET Framework regisztrálása-újraregisztrálása IIS alá Web rendszer-adminisztrációs felület AD Autentikáció Web szerver indítási feltételek Terheléselosztás Kliens telepítése Hálózati beállítások Neptun címtárszolgáltatás A címtárszolgáltatás leírása A címtárszolgáltatás funkciói A címtárszolgáltatás paraméterei A címtárszolgáltatás működése A címtárszolgáltatás beállítása Elektronikus aláírás és számlázás feltételei Médiumok Típusok Telepítés Kompromittálódás Elektronikus számlázáshoz szükséges beállítások Tanúsítványkezelés Neptun.NET rendszerekben Tanúsítvány Neptun.NET kiszolgáló futtatásához Tanúsítványok elektronikus számlázáshoz Főtanúsítványok, hitelesítés-szolgáltatók FIR tanúsítványok Aláíró tanúsítvány kliens oldali aláírás esetén Aláíró tanúsítvány szerver oldali aláírás esetén FIR kommunikációs csatornával kapcsolatos állományok FIR aláírás metódusának kiválasztása Kapcsolat a Diákhitel-rendszerrel Rendelkezésre állás Adatbázis üzemeltetése Mentés és helyreállítás Beállítások Ütemezés Tesztelés Megfigyelés Kiadás: Verzió: 3.10 Oldalszám: 5 / 231

6 Visszaállítás Helyreállítás Adatbázis mentése és helyreállítása Oracle adatbázison Adatbázis mentése NOARCHIVELOG módban Adatbázis visszaállítása NOARCHIVELOG módban Adatbázis mentése ARCHIVELOG módban Adatbázis mentése ARCHIVELOG módban, RMAN segítségével Adatbázis helyreállítása ARCHIVELOG módban A teljes és a részleges helyreállítás összehasonlítása Lemezhiba és helyreállítás ARCHIVELOG módban Katasztrófaterv Katasztrófaterv szükségessége Megelőző intézkedések Katasztrófa esetén értesítendő személyek Keletkezett kár felmérése Helyreállítás Teszt rendszerek Tesztrendszer fogalma Tesztrendszer naprakészen-tartása, éles adatok időszakos áttöltése Adatok áttöltése Oracle adatbázis-kezelő rendszeren Adatok áttöltése MSSQL adatbázis-kezelő rendszeren Verzió kihelyezés A verzió kihelyezés esemény előzménye Igénylés, végrehajtás, értesítés Verzió- és javítócsomag kihelyezése Licenszállomány kihelyezésének és cseréjének folyamata LOB típusú oszlopok konverziója FIR XML szétbontás, konténerek tömörítése Adatgyűjtés, statisztika, riportok Rendszer működéséről Adatbázis működése Adatgyűjtés a Neptun működéséről Tárgyfelvételek száma Vizsgajelentkezések száma Biztonságtechnikai megoldások Adat- és információvédelem Komplex informatikai biztonság Az adatvédelem célja Teljes körű védelem Megoldások körei Általános adatvédelmi megoldások Fizikai védelem Hardveres védelem Szoftveres védelem Megfelelő lépések és kockázatbecslés Neptun.NET rendszer biztonsági megoldások Kiadás: Verzió: 3.10 Oldalszám: 6 / 231

7 Adattitkosítás az alkalmazás és adatbázis szerverek között Alkalmazásszerver és kliens közötti biztonságtechnikai lehetőségek Neptun.NET web kliensek adatforgalmának védelme Webreugrás webservice biztonsági lehetőségek Jogosultság és szerepkör Használjon erős jelszavakat Jelszavak tárolása Jelszó szabályok Neptun.NET rendszer beléptetési metódusai Hagyományos jelszavas autentikáció Központi autentikáció használatával Konfigurációs állományok védelme Reaktív és proaktív tevékenységek Adatbázisszerver védelme Felhasználók képzése Együttműködés a Poszeidon rendszerrel Együttműködés fogalma Adatbázis kialakítása Együttműködési sémanév beállítása Verzió kompatibilitás Tesztrendszer frissítése Szószedet Kiadás: Verzió: 3.10 Oldalszám: 7 / 231

8 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: Verzió: 3.10 Oldalszám: 8 / 231

9 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: Verzió: 3.10 Oldalszám: 9 / 231

10 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 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 ( ) Standard, Standard One vagy Enterprise Edition Microsoft SQL Server 2008 R2 Service Pack 2 Microsoft SQL Server 2012 Kiadás: Verzió: 3.10 Oldalszám: 10 / 231

11 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: Verzió: 3.10 Oldalszám: 11 / 231

12 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:fir@ftp.sdakft.hu/szerverinstall/ibmmq7.exe Szolgáltatói tanúsítványok telepítője ftp://fir:fir@ftp.sdakft.hu/szerverinstall/szolgaltatoi_tanusitvanyok_telepitese.exe FIR rendszer használata esetén a SDA.FIR.Configurator alkalmazás ftp://fir:fir@ftp.sdakft.hu/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: Verzió: 3.10 Oldalszám: 12 / 231

13 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 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: Verzió: 3.10 Oldalszám: 13 / 231

14 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: Verzió: 3.10 Oldalszám: 14 / 231

15 használata, de csak abban az esetben, ha az nem befolyásolja, ill. módosítja az adatforgalmat 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: Verzió: 3.10 Oldalszám: 15 / 231

16 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: Verzió: 3.10 Oldalszám: 16 / 231

17 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 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: Verzió: 3.10 Oldalszám: 17 / 231

18 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 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: Verzió: 3.10 Oldalszám: 18 / 231

19 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 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: Verzió: 3.10 Oldalszám: 19 / 231

20 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! 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 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: Verzió: 3.10 Oldalszám: 20 / 231

21 Amennyiben nem adott meg 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: Verzió: 3.10 Oldalszám: 21 / 231

22 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: Verzió: 3.10 Oldalszám: 22 / 231

23 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: Verzió: 3.10 Oldalszám: 23 / 231

24 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: Verzió: 3.10 Oldalszám: 24 / 231

25 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: Verzió: 3.10 Oldalszám: 25 / 231

26 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: Verzió: 3.10 Oldalszám: 26 / 231

27 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 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: Verzió: 3.10 Oldalszám: 27 / 231

28 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: Verzió: 3.10 Oldalszám: 28 / 231

29 Á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: Verzió: 3.10 Oldalszám: 29 / 231

30 Ezzel visszakapjuk az első oldalt, melyen a Befejezés gombra kattintva tudjuk a konfiguráló programot bezárni 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: Verzió: 3.10 Oldalszám: 30 / 231

31 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: Verzió: 3.10 Oldalszám: 31 / 231

32 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 Notifications -t. Adjunk meg egy elérhető smtp szervert ( Outgoing Mail (SMTP) Server ) és egy címet ( 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: Verzió: 3.10 Oldalszám: 32 / 231

33 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: Verzió: 3.10 Oldalszám: 33 / 231

34 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: Verzió: 3.10 Oldalszám: 34 / 231

35 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: Verzió: 3.10 Oldalszám: 35 / 231

36 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: Verzió: 3.10 Oldalszám: 36 / 231

37 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 processes sessions Kiadás: Verzió: 3.10 Oldalszám: 37 / 231

38 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 (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: Verzió: 3.10 Oldalszám: 38 / 231

39 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: Verzió: 3.10 Oldalszám: 39 / 231

40 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 küldő szolgáltatást és változtassunk az intézmény által megkövetelt metrikák szintjén 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: Verzió: 3.10 Oldalszám: 40 / 231

41 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: Verzió: 3.10 Oldalszám: 41 / 231

42 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; 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> -- NEPTUN3R felhasználó létrehozása SQL> -- Connect sys as sysdba SQL> CREATE USER NEPTUN3R SQL> IDENTIFIED BY PA$$WORD SQL> DEFAULT TABLESPACE NEPTUN3R_DAT SQL> TEMPORARY TABLESPACE NEPTUN3R_TMP SQL> PROFILE DEFAULT SQL> 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: Verzió: 3.10 Oldalszám: 42 / 231

43 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> -- NEPTUN3R_LOG felhasználó létrehozása SQL> -- Connect sys as sysdba SQL> CREATE USER NEPTUN3R_LOG SQL> IDENTIFIED BY PA$$WORD SQL> DEFAULT TABLESPACE NEPTUN3R_LOG SQL> TEMPORARY TABLESPACE NEPTUN3R_TMP SQL> PROFILE DEFAULT SQL> ACCOUNT UNLOCK; 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: Verzió: 3.10 Oldalszám: 43 / 231

44 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 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: Verzió: 3.10 Oldalszám: 44 / 231

45 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: Verzió: 3.10 Oldalszám: 45 / 231

46 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: Verzió: 3.10 Oldalszám: 46 / 231

47 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: Verzió: 3.10 Oldalszám: 47 / 231

48 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: Verzió: 3.10 Oldalszám: 48 / 231

49 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: Verzió: 3.10 Oldalszám: 49 / 231

50 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: Verzió: 3.10 Oldalszám: 50 / 231

51 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: Verzió: 3.10 Oldalszám: 51 / 231

52 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: Verzió: 3.10 Oldalszám: 52 / 231

53 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: Verzió: 3.10 Oldalszám: 53 / 231

54 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 <<browse >> 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: Verzió: 3.10 Oldalszám: 54 / 231

55 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: Verzió: 3.10 Oldalszám: 55 / 231

56 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: Verzió: 3.10 Oldalszám: 56 / 231

57 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: Verzió: 3.10 Oldalszám: 57 / 231

58 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 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: Verzió: 3.10 Oldalszám: 58 / 231

59 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: Verzió: 3.10 Oldalszám: 59 / 231

60 Első lépésben a telepíteni kívánt projekthez (Neptun, Poszeidon, Unipoll, Teszt-Neptun, Teszt- Poszeidon, 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: Verzió: 3.10 Oldalszám: 60 / 231

61 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: Verzió: 3.10 Oldalszám: 61 / 231

62 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: Verzió: 3.10 Oldalszám: 62 / 231

63 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 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: Verzió: 3.10 Oldalszám: 63 / 231

64 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: Verzió: 3.10 Oldalszám: 64 / 231

65 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: Verzió: 3.10 Oldalszám: 65 / 231

66 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: Verzió: 3.10 Oldalszám: 66 / 231

67 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: Verzió: 3.10 Oldalszám: 67 / 231

68 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 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: Verzió: 3.10 Oldalszám: 68 / 231

69 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: Verzió: 3.10 Oldalszám: 69 / 231

70 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: Verzió: 3.10 Oldalszám: 70 / 231

71 2.2. Alkalmazás szerver telepítése 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: Verzió: 3.10 Oldalszám: 71 / 231

72 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: Verzió: 3.10 Oldalszám: 72 / 231

73 Oracle kliens telepítése: A jelenleg támogatott Oracle verzió a 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: Verzió: 3.10 Oldalszám: 73 / 231

74 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: Verzió: 3.10 Oldalszám: 74 / 231

75 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: Verzió: 3.10 Oldalszám: 75 / 231

76 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: Verzió: 3.10 Oldalszám: 76 / 231

77 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: Verzió: 3.10 Oldalszám: 77 / 231

78 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: Verzió: 3.10 Oldalszám: 78 / 231

79 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: Verzió: 3.10 Oldalszám: 79 / 231

80 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 Nem managelt DataAccess A 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: Verzió: 3.10 Oldalszám: 80 / 231

81 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: Verzió: 3.10 Oldalszám: 81 / 231

82 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 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: Verzió: 3.10 Oldalszám: 82 / 231

83 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 Az Oracle DataProvider regisztrálása, újraregisztrálása GAC-ba A Neptun.NET 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: Verzió: 3.10 Oldalszám: 83 / 231

84 C:\Oracle\client\odp.net\bin\4\OraProvCfg.exe /action:gac /providerpath:oracle.dataaccess.dll 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 Nevesített Windows Service telepítése Az SDA Informatika Zrt. által fejlesztett SDAServerService.exe telepíthető tetszőleges névvel. Kiadás: Verzió: 3.10 Oldalszám: 84 / 231

85 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\v \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\v \ 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: Verzió: 3.10 Oldalszám: 85 / 231

86 Lesz még szükség beállításra a FIR miatt, de azt majd ott részletezzük. Ld.: 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: Verzió: 3.10 Oldalszám: 86 / 231

87 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: Verzió: 3.10 Oldalszám: 87 / 231

88 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 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: Verzió: 3.10 Oldalszám: 88 / 231

89 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: Verzió: 3.10 Oldalszám: 89 / 231

90 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: Verzió: 3.10 Oldalszám: 90 / 231

91 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 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: Verzió: 3.10 Oldalszám: 91 / 231

92 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: 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: Verzió: 3.10 Oldalszám: 92 / 231

93 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 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:fir@ftp.sdakft.hu/szerverinstall Kiadás: Verzió: 3.10 Oldalszám: 93 / 231

94 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: Verzió: 3.10 Oldalszám: 94 / 231

95 Kiadás: Verzió: 3.10 Oldalszám: 95 / 231

96 Kiadás: Verzió: 3.10 Oldalszám: 96 / 231

97 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 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: Verzió: 3.10 Oldalszám: 97 / 231

98 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: Verzió: 3.10 Oldalszám: 98 / 231

99 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! 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:fir@ftp.sdakft.hu/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: Verzió: 3.10 Oldalszám: 99 / 231

100 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: Verzió: 3.10 Oldalszám: 100 / 231

101 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 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 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: Verzió: 3.10 Oldalszám: 101 / 231

102 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. 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: Verzió: 3.10 Oldalszám: 102 / 231

103 ECHO Hasznalt parameter: %name% ECHO Kapcsolat tipus: 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: Verzió: 3.10 Oldalszám: 103 / 231

104 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:fir@ftp.sdakft.hu/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 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: Verzió: 3.10 Oldalszám: 104 / 231

105 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. <?xml version="1.0"?> <configuration> <configsections> </configsections> <ServerConfig type="sda.framework.remoting.configuration.sdaserversettings, SDA.Framework.Remoting"> </ServerConfig> <runtime> <loadfromremotesources enabled="true"/> <assemblybinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentassembly> <assemblyidentity name="oracle.dataaccess" Kiadás: Verzió: 3.10 Oldalszám: 105 / 231

106 publickeytoken="89b483f429c47342" /> <bindingredirect oldversion=" " newversion=" " /> </dependentassembly> </assemblybinding> </runtime> <startup> <supportedruntime version="v4.0" sku=".netframework,version=v4.0"/> </startup> </configuration> 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 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: Verzió: 3.10 Oldalszám: 106 / 231

107 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: Verzió: 3.10 Oldalszám: 107 / 231

108 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 Ü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 ü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: Verzió: 3.10 Oldalszám: 108 / 231

109 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ú ( , 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: Verzió: 3.10 Oldalszám: 109 / 231

110 Az küldést engedélyezni az Enabled sorban lehet, de ez önmagában nem elegendő. Ki kell legyen töltve az SMTP_Host ugyanis, ez feltétele az 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 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 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 ek ü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: sendingblockcount : 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. sendingtime : 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 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: Verzió: 3.10 Oldalszám: 110 / 231

111 Nagyon fontos tudni, hogy az intézményi SMTP szerver hogyan van beállítva. Ugyanis kétféle küldési beállítás van. Az első, hogy a SDA.ConfigEditor-ban beállított feladó, minden 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 küldés. A második eset, amikor az üzenet készítője az 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 címe lesz az feladója. Amennyiben az SMTP szerveren nincs engedélyezve, hogy bármilyen (nem intézményi) címről küldjön levelet, az alkalmazás szerver nem tudja kiküldeni az -eket LMS telepítése 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: Verzió: 3.10 Oldalszám: 111 / 231

112 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! 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! 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: <add key="datapersistanceengine" value="oracle" /> SCORM db connectionstring-je. <add key="databaseconnectionstring" value="server=tnsalias;uid=lmsuser;pwd=jelszo" /> Neptun db connectionstring-je. <add key="neptundatabaseconnectionstring" value="data Source=tnsalias;User Id=neptunuser;Password=jelszo"/> A cormengineinterface relatív url-je. <add key="scormengineurl" value="/neptunlms/scormengineinterface" /> A tananyagból kilépve ide irányít át a rendszer. Alapértelmezetten bezárja a lejátszó ablakát. <add key="redirectonexiturl" Kiadás: Verzió: 3.10 Oldalszám: 112 / 231

113 /> value=" 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"/> <authentication mode="forms"> <forms loginurl="~/login.aspx" enablecrossappredirects="true" name=".cookiesharing" slidingexpiration="true" protection="encryption" defaulturl="~/default.aspx" path="/" timeout="2880" /> </authentication> 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: <authorization> <deny users="?"/> </authorization> A LMSService/web.config ban az alábbi bejegyzéseket szerkessze meg: SCORM db connectionstring-je: <add key="databaseconnectionstring" value="data Source=tnsalias;User Id=lmsuser;Password=jelszo"/> A létrehozott ScormEngineInterface url-je <add key="scormengineurl" value=" Neptun DB connectionstring-je: <add key="neptundatabaseconnectionstring" value="data Source=tnsalias;User Id=neptunuser;Password=jelszo"/> Az adatbázismotor típusa, egyelőre csak Oracle lehet: <add key="datapersistanceengine" value="oracle"/> A Contentroot mappa elérése: <add key="webpathtocontentroot" value="/neptunlms/contentroot"/> A Contentroot/files mappa fizikai útvonala: Kiadás: Verzió: 3.10 Oldalszám: 113 / 231

114 <add key="filepathtocontentroot" value="c:\neptunlms\contentroot\files\"/> A Contentroot/zips mappa fizikai útvonala: <add key="filepathtouploadedzippedpackage" value="c:\neptunlms\contentroot\zips"/> Request szűrés beállítás: <system.webserver> <security> <requestfiltering> <requestlimits maxallowedcontentlength=" " /> </requestfiltering> </security> </system.webserver> 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 <!--SCORM ENGINE SETTINGS--> <!--Tananyag feltöltő szolgáltatás--> <add key="neptunlmsservice" value=" A scorm db connectionstringje: <!--E-learning adatbázis connectionstring-je--> <add key="databaseconnectionstring" value="data Source=tnsalias;User Id=lmsuser;Password=jelszo"/> MachineKey és autentikáció beállítása: <machinekey decryption="auto" decryptionkey="xxxxxx" validation="sha1" validationkey="xxxxxx"/> <authentication mode="forms"> <forms loginurl="~/login.aspx" enablecrossappredirects="true" name=".cookiesharing" slidingexpiration="true" protection="encryption" defaulturl="~/default.aspx" path="/" timeout="2880" /> </authentication> Az autorizációs részt itt nem kell megadni, ez csak lms autentikációjához szükséges. Kiadás: Verzió: 3.10 Oldalszám: 114 / 231

115 LDAP szervizek telepítési dokumentációja 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! 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! 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 <add key="neptunserverconnection" value=" /> 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 <add key="ldapclientip" value=" , " /> 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: Verzió: 3.10 Oldalszám: 115 / 231

116 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 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 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) 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: Verzió: 3.10 Oldalszám: 116 / 231

117 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 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: Verzió: 3.10 Oldalszám: 117 / 231

118 A gombra kattintva előjön a beállítás panel. Kiadás: Verzió: 3.10 Oldalszám: 118 / 231

119 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 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: Verzió: 3.10 Oldalszám: 119 / 231

120 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 WEB alkalmazás 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 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: Verzió: 3.10 Oldalszám: 120 / 231

121 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 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: Verzió: 3.10 Oldalszám: 121 / 231

122 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: Verzió: 3.10 Oldalszám: 122 / 231

123 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: Verzió: 3.10 Oldalszám: 123 / 231

124 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: Verzió: 3.10 Oldalszám: 124 / 231

125 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: Verzió: 3.10 Oldalszám: 125 / 231

126 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: Verzió: 3.10 Oldalszám: 126 / 231

127 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: Verzió: 3.10 Oldalszám: 127 / 231

128 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: Verzió: 3.10 Oldalszám: 128 / 231

129 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: Verzió: 3.10 Oldalszám: 129 / 231

130 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: Verzió: 3.10 Oldalszám: 130 / 231

131 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: Verzió: 3.10 Oldalszám: 131 / 231

132 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: Verzió: 3.10 Oldalszám: 132 / 231

133 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: Verzió: 3.10 Oldalszám: 133 / 231

134 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: Verzió: 3.10 Oldalszám: 134 / 231

135 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 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\v \aspnet_regiis.exe -i 64 bites rendszer esetén: C:\Windows\Microsoft.NET\Framework64\v \aspnet_regiis.exe -i Kiadás: Verzió: 3.10 Oldalszám: 135 / 231

136 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 ( 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.: /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.: vagy az engedélyezett adminisztrátori gépekről a szokásos teljes URL-es formában meghívva: Kiadás: Verzió: 3.10 Oldalszám: 136 / 231

137 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. <?xml version="1.0" encoding="utf-8"?> <webservers> <webserver name="egyik web" url=" 3.5"></webserver> <webserver name="masik web" url=" 3.5"></webserver> </webservers> 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: Verzió: 3.10 Oldalszám: 137 / 231

138 (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: Verzió: 3.10 Oldalszám: 138 / 231

139 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: Verzió: 3.10 Oldalszám: 139 / 231

140 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: Verzió: 3.10 Oldalszám: 140 / 231

141 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 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 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: Verzió: 3.10 Oldalszám: 141 / 231

142 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: Verzió: 3.10 Oldalszám: 142 / 231

143 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 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: Verzió: 3.10 Oldalszám: 143 / 231

144 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. <?xml version="1.0"?> <configuration> <configsections> <section name="serverconfig" type="configsectionhandler"> </section> </configsections> <runtime> <loadfromremotesources enabled="true" /> <assemblybinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentassembly> <assemblyidentity name=" Oracle.DataAccess" publickeytoken="89b483f429c47342" culture="neutral" /> <bindingredirect oldversion=" " newversion=" " /> </dependentassembly> </assemblybinding> </runtime> Kiadás: Verzió: 3.10 Oldalszám: 144 / 231

145 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(" if (a==1) go_to(" if (a==2) go_to(" if (a==3) go_to(" if (a==4) go_to(" if (a==5) go_to(" } function rand_link_okt() { var a; a = Math.round(Math.random()); // a = random számok 0-1 if (a==0) go_to(" vagy név)/oktato"); if (a==1) go_to(" vagy név)/oktato_1"); } </SCRIPT> 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: Verzió: 3.10 Oldalszám: 145 / 231

146 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 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 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: Verzió: 3.10 Oldalszám: 146 / 231

147 2.6. Neptun címtárszolgáltatás 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 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: Verzió: 3.10 Oldalszám: 147 / 231

148 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 Microsoft Active Directory edirectory 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 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 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: Verzió: 3.10 Oldalszám: 148 / 231

149 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: Verzió: 3.10 Oldalszám: 149 / 231

150 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 Microsoft Active Directory edirectory (OpenLDAP) Vezetéknév SN SN Keresztnév givenname GN Teljes név displayname displayname Neptunkód description és employeeid description és employeeid (ez az attribútum nem létezik, ezért egy NeptunAccount kiegészítő sémában létre kell hozni!) Bejelentkezési azonosító samaccountname CN Bejelentkezési userprincipalname azonosító@domain név Kiadás: Verzió: 3.10 Oldalszám: 150 / 231

151 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: Verzió: 3.10 Oldalszám: 151 / 231

152 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: Verzió: 3.10 Oldalszám: 152 / 231

153 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) 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: Verzió: 3.10 Oldalszám: 153 / 231

154 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 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: Verzió: 3.10 Oldalszám: 154 / 231

155 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 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: Verzió: 3.10 Oldalszám: 155 / 231

156 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: Verzió: 3.10 Oldalszám: 156 / 231

157 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 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 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: Verzió: 3.10 Oldalszám: 157 / 231

158 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 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ó 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: Verzió: 3.10 Oldalszám: 158 / 231

159 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: Verzió: 3.10 Oldalszám: 159 / 231

160 - 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 CertificateIssuerName CertificateSerialNumber CertificateStoreName City ClientID CopyMaker CopyPolicyURI Country CreateSignedCertificate CreateSignedDocument PaperSize PdfMetaDataAuthor PdfMetaDataTitle, PdfMetaDataComment, Kötelező Leírás tanúsítványból a kiállítójának neve, a tanúsítvány sorozatszáma, a tanúsítványból kell kimásolni, alapértelmezett tároló a "My", ezen ne változtassunk! a település neve, ahová az intézmény be van jegyezve, az SDA által kiadott kliensazonosító, az időbélyeg lekérésekhez van szükség rá, a másolat kiadó szervezet neve (intézménynév), az intézmény másolatkészítési szabályzatának URI-ja, az ország neve, ahová az intézmény be van jegyezve, készülhet-e elektronikus adóigazolás, csak akkor működik, ha a CreateSignedDocument" engedélyezve van. készülhet-e elektronikusan aláírt dokumentum a generált PDF állományok papírmérete dokumentum készítője dokumentum címe megjegyzés Kiadás: Verzió: 3.10 Oldalszám: 160 / 231

161 PdfMetaDataSubject dokumentum tárgya PostalCode az intézmény irányítószáma Priority időbélyeg prioritás - maradjon a default értéken 5 StateOrProvince intézmény állam/megye TestMode true, ha tesztrendszer, false, ha éles üzemi kiszolgáló TimeStampServerURI időbélyegszerver címe: 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: 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: A főtanúsítványokról a 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: Verzió: 3.10 Oldalszám: 161 / 231

162 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: Verzió: 3.10 Oldalszám: 162 / 231

163 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: Verzió: 3.10 Oldalszám: 163 / 231

164 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 FIR tanúsítványok 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 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: Verzió: 3.10 Oldalszám: 164 / 231

165 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 v legyen! <?xml version="1.0" encoding="utf-8"?> <configuration> <startup> <supportedruntime version="v " /> </startup> 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: Verzió: 3.10 Oldalszám: 165 / 231

166 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 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 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: Verzió: 3.10 Oldalszám: 166 / 231

167 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: a tesztrendszeré pedig: 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: Verzió: 3.10 Oldalszám: 167 / 231

168 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: Verzió: 3.10 Oldalszám: 168 / 231

169 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: Verzió: 3.10 Oldalszám: 169 / 231

170 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: Verzió: 3.10 Oldalszám: 170 / 231

171 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: Verzió: 3.10 Oldalszám: 171 / 231

172 Lépjen tovább, egy összefoglalást láthat: Ezután már a sikeres telepítésről kell értesülnie: Kiadás: Verzió: 3.10 Oldalszám: 172 / 231

173 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! Pl.: DefaultAppPool esetén: IIS AppPool\DefaultAppPool, Tesztkeszlet 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: Verzió: 3.10 Oldalszám: 173 / 231

174 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: Verzió: 3.10 Oldalszám: 174 / 231

175 A képen látható URL a TESZT DiákHitelService URL-je tesztrendszer esetén ezt állítsák be! Éles rendszer esetén: ( ). 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: Verzió: 3.10 Oldalszám: 175 / 231

176 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: Verzió: 3.10 Oldalszám: 176 / 231

177 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 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: Verzió: 3.10 Oldalszám: 177 / 231

178 Ü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 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 Ü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: Verzió: 3.10 Oldalszám: 178 / 231

179 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! 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 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: Verzió: 3.10 Oldalszám: 179 / 231

180 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 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 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 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: Verzió: 3.10 Oldalszám: 180 / 231

181 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 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 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: Verzió: 3.10 Oldalszám: 181 / 231

182 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 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 Production on H. Mßrc :29: Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. hozzßkapcsolˇdva a cúladatbßzishoz: NEPTUN3R (DBID= ) a cúladatbßzis vezúrl fßjljßnak hasznßlata a helyreßllýtßsi katalˇgus helyett RMAN> show all; Kiadás: Verzió: 3.10 Oldalszám: 182 / 231

183 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: Verzió: 3.10 Oldalszám: 183 / 231

184 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: Verzió: 3.10 Oldalszám: 184 / 231

185 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! 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) 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: Verzió: 3.10 Oldalszám: 185 / 231

186 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 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: Verzió: 3.10 Oldalszám: 186 / 231

187 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 OFFLINE 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: Verzió: 3.10 Oldalszám: 187 / 231

188 THREAD# SEQUENCE# TIME ARCHTVE_NAME SEP-O7 /u0l/oradata/archive/arch_34.rdo SEP-O7 /u0l/oradata/archive/arch_43.rdo 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 <number> <name> Csak nyitott adatbázis esetén alkalmazható. RECOVER [AUTOMATIC] DATAFILE <number> <name> 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 <new location>; Kiadás: Verzió: 3.10 Oldalszám: 188 / 231

189 Használjuk a RECO VER FROM <location> parancsot: SQL> RECOVER FROM <new location> 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 /21/07 17:00:14 needed for thread 1 ORA-00289: suggestion: /u0l/archive/arch_34.rdo ORA-00280: change for thread 1 is in sequence #34 Specify log: {<RET>=suggested filename AUTO CANCEL} AUTO Log applied.... Használjuk az AUTOMATIC opciót a RECOVER parancsban: SQL> RECOVER AUTOMATIC DATAFILE 4 Media recovery complete Katasztrófaterv 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 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: Verzió: 3.10 Oldalszám: 189 / 231

190 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 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 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 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: Verzió: 3.10 Oldalszám: 190 / 231

191 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 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 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: Verzió: 3.10 Oldalszám: 191 / 231

192 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> -- Oracle Directory létrehozása SQL> -- Connect sys as sysdba SQL> CREATE OR REPLACE DIRECTORY BACKUP_DIR AS 'F:\oracle\export\'; SQL> Directory Created SQL> 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: Verzió: 3.10 Oldalszám: 192 / 231

193 FLASHBACK_TIME= to_timestamp( :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 REMAP_SCHEMA és a REMAP_TABLESPACE kifejezés. felhasználók, akkor a parancsból elhagyható a Kiadás: Verzió: 3.10 Oldalszám: 193 / 231

194 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! 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: Verzió: 3.10 Oldalszám: 194 / 231

195 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: Verzió: 3.10 Oldalszám: 195 / 231

196 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 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: Verzió: 3.10 Oldalszám: 196 / 231

197 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 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: Verzió: 3.10 Oldalszám: 197 / 231

198 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: Verzió: 3.10 Oldalszám: 198 / 231

199 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ő 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 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: Verzió: 3.10 Oldalszám: 199 / 231

200 Frissítés indítása előtti ellenőrzés: 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: 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: Verzió: 3.10 Oldalszám: 200 / 231

201 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: Verzió: 3.10 Oldalszám: 201 / 231

202 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: Verzió: 3.10 Oldalszám: 202 / 231

203 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 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 > 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 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 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: Verzió: 3.10 Oldalszám: 203 / 231

204 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 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: Verzió: 3.10 Oldalszám: 204 / 231

205 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 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: Verzió: 3.10 Oldalszám: 205 / 231

206 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: Verzió: 3.10 Oldalszám: 206 / 231

207 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: <ConvertConfiguration> <Tables> <Table Name="[tábla_név]"> <Converts> <Convert> <SourceColumn>[átnevezett BLOB típusú oszlop]</sourcecolumn> <DestinationColumn>[új CLOB típusú oszlop]</destinationcolumn> </Convert> </Converts> </Table> </Tables> </ConvertConfiguration> MSSQL adatbázisok esetén IMAGE adattípust konvertálunk NTEXT típusra, a fent leírtakkal teljesen azonos módon 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: Verzió: 3.10 Oldalszám: 207 / 231

208 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: Verzió: 3.10 Oldalszám: 208 / 231

209 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: Verzió: 3.10 Oldalszám: 209 / 231