KONFIGURÁCIÓ-MENEDZSMENT

Átírás

1

2 DIPLOMAMUNKA KONFIGURÁCIÓ-MENEDZSMENT VERZIÓKÖVETETT OBJEKTUMOKKAL Budapesti Műszaki és Gazdaságtudományi Egyetem Irányítástechnika és Informatika Tanszék Készítette: Fülöp Balázs EIWMWH Konzulens: Dr. Szeberényi Imre Budapest, 2009

3

4 DIPLOMATERV FELADAT Fülöp Balázs szigorló műszaki informatikus hallgató részére Konfiguráció-menedzsment verziókövetett objektumokkal Összetett, gyakran változó rendszerek konfiguráció-menedzsmentje nem egyszerű feladat. Kis- és nagyvállalatokon belül egyaránt fontos az informatikai szolgáltatásokat nyújtó infrastruktúra konfigurációjának rugalmas, naprakész nyilvántartása, egyszerű módosítása. A diplomaterv feladat során a cél egy rugalmas konfiguráció-menedzsment környezet fő elemeinek objektum orientált megvalósítása, amely verziókövetett módon nyújtja az objektum orientált rendszerek előnyeit. Feladatok: 1. Elemezze a konfiguráció-menedzsmenttel kapcsolatos fő feladatokat egy feltételezett cég belső informatikai infrastruktúra szolgáltatásának szempontjából. 2. Tervezzen meg egy olyan keretrendszert, mely alapját képezheti a konfigurációmenedzsment feladatok verziókövetett megoldásának 3. Válasszon az implementáláshoz megfelelő, lehetőleg gyors fejlesztéshez jól használható nyelvet és implementálja a megtervezett keretrendszert. 4. Demonstrálja az elkészített rendszer működését, és készítse a fejlesztői dokumentációját. A feladat beadási határideje: május 15. Tanszéki konzulens: Dr. Szeberényi Imre Záróvizsga tárgyak: Rendszerintegráció (BMEVIFO4367) Operációs rendszerek (BMEVIM3231) Adatbázisok (BMEVIIA3232) Budapest, február 20. Dr. Szirmay-Kalos László egyetemi tanár TANSZÉKVEZETŐ Budapesti Mű szaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Irányítástechnika és Informatika Tanszék 1117 Budapest, Magyar tudósok körútja 2. I. ép Postacím: 1521 Budapest, Pf.: 91. Tel: , Fax: ,

5

6 Konfiguráció-menedzsment verziókövetett objektumokkal 6 Nyilatkozat Alulírott Fülöp Balázs, a Budapesti Műszaki és Gazdaságtudományi Egyetem hallgatója kijelentem, hogy jelen diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, amelyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Budapest, május Fülöp Balázs

7

8 Konfiguráció-menedzsment verziókövetett objektumokkal 8 Tartalomjegyzék I. Előszó II. Abstract III. Konfiguráció-menedzsment A konfiguráció-menedzsment célja IBM Tivoli platform BMC Modellezési kihívások XML alapú modellezés LDAP alapú modellezés Objektum-relációs leképezés Gyenge sémájú relációs modellezés CM modellezési eljárások összehasonlítása IV. Adatmodell gyenge sémájú modellezéshez Az adatmodell követelményei Entitás-relációk tervezése Relációs séma tervezése ActLog tábla ObjTree tábla ObjRev tábla ObjType tábla ObjAttr tábla AttrKey tábla AttrVal tábla V. A Perl nyelv A nyelv eredete A Perl adattípusai A Perl és az OOP Beépített típusok egyedi implementációja VI. A Calf keretrendszer A keretrendszer célja A keretrendszer áttekintése Calf csomag Calf::Tie csomagok Calf::Object csomagok Calf::DB csomagok Calf::Data csomag A keretrendszer használatának bemutatása

9 Konfiguráció-menedzsment verziókövetett objektumokkal 9 I. Előszó Jelen dokumentum a 2008/09. tanév tavaszi félévében, a Budapesti Műszaki és Gazdaságtudományi Egyetem műszaki informatikus szakán írt diplomamunkámat tartalmazza. Önállóan választott témám a Perl 5 programozási környezet objektum-perzisztencia képességeinek feltérképezése és továbbfejlesztése, valamint ezek egyedi konfigurációmenedzsment rendszerekben való alkalmazhatóságának vizsgálata. A téma és a kitűzött feladatok hálás kihívást jelentettek abból a szempontból, hogy egy olyan jellemzően nagyvállalati környezetben felmerülő igény problémáit érintik, melyekre magától értetődően jó gyakorlat, tipikus és szélesebb körben elismert megoldás egyelőre nem létezik. Ezért a munka nagy része izgalmas kísérletezésből és kreatív fejlesztésből állt. Másrészről a témaválasztás kevéssé mondható szerencsésnek, mert nem egyértelmű meghúzni azt a határvonalat, ahol a szűkös időkeret szorításában a kutatás-fejlesztés szakasza le kell, hogy záruljon. Mivel a diplomamunka gerincét adó dolgozatnak egy ponton össze kell foglalnia az eredményeket, a szerteágazó problémakör egyes elemei természetszerűleg több hangsúlyt kaptak, mint mások. Végeredményben jelen diplomamunka egyik fő eredménye egy Perl5-höz készült, széles körű felhasználásra alkalmas, verziókövető képességekkel bíró perzisztencia-réteg. E sokrétű feladat meghatározó elemeinek kiemelésében rendkívüli segítséget nyújtott számomra Dr. Szeberényi Imre, akinek támogatásáért ezúton szeretnék köszönetet mondani. Szeretném továbbá megköszönni mindazoknak az együttműködését, akik elolvasták a dolgozatomat, és kritikáikkal, építő megjegyzéseikkel segítették a munkámat: Fülöp Edinának, Hámor Tamásnak, Kornai Tamásnak, Köllő Tamásnak és Székely Gergőnek. Budapest, május Fülöp Balázs

10 Konfiguráció-menedzsment verziókövetett objektumokkal 10 II. Abstract This document contains my final thesis for the Faculty of IT Engineering at the Budapest University of Technology and Economics, written in the spring semester of 2008/09. The main topic of the thesis that has been chosen independently is the examination and enhancement of the object persistence capacities of the Perl5 programming environment. The question of the strengths and weaknesses of deploying a custom configuration management system built on top of that has been addressed as well. The topic and the actual tasks imposed a number of exciting challenges concerning enterpriselevel problems, for which apparent best practices, or widely deployed universal solutions are not available. Because of that a great amount of efforts has been spent on experimental development. Defining the actual point where the phase of research and development needs to be closed due to time limitation was a challenge by itself. Since the documentation part of the thesis needs to summarize the results of the work in the end of the day, certain elements of the diversified problem scope have gotten a greater emphasis than others. One of the main accomplishments of the thesis is a fully featured persistence layer for Perl5 with versioning capabilities, intended for general use. I would like to thank Imre Szeberényi, Dr. for his tiredless efforts to help in finding the key points to focus on. I would also like to say thank you to all of those who have read an earlier revision of my thesis and provided feedback: Edina Fülöp, Tamás Hámor, Tamás Kornai, Tamás Köllő and Gergő Székely. Budapest, 14 th May Fülöp Balázs

11 Konfiguráció-menedzsment verziókövetett objektumokkal 11 III. Konfiguráció-menedzsment Mottó: Nehéz úgy érvényes általánosításokat kijelenteni, hogy mondunk is valamit. Ez nincs másként az előző mondat esetében sem. 1. A konfiguráció-menedzsment célja Általános értelemben a konfiguráció-menedzsment (a továbbiakban: CM) az informatikában inkább egy koncepció, mint egy valódi szabvány. Pontosabban fogalmazva, a kiadott szabványok nagy, és a referencia implementációk kis száma miatt igen nehéz egy olyan definíciót adni rá, amely minden szervezet CM rendszerére illeszkedne. A Wikipedia Configuration management[1] szócikke az alábbi szabványok listáját tartalmazza: ANSI/EIA National Consensus Standard for Configuration Management EIA-649-A 2004 National Consensus Standard for Configuration Management ISO 10007:2003 Quality management systems - Guidelines for configuration management Federal Standard 1037C GEIA Standard Configuration Management Data Exchange and Interoperability IEEE Std IEEE Standard for Software Configuration Management Plans MIL-STD-973 Configuration Management (2000. szeptember 20-án visszavonták) STANAG 4159 NATO Material Configuration Management Policy and Procedures for Multinational Joint Projects STANAG 4427 Introduction of Allied Configuration Management Publications (ACMPs) Közös vonásuk, hogy egy informatikai rendszer komponenseinek konfigurációit állapotként kezelik és elsődleges célként a rendszer konzisztens állapotból konzisztens állapotba történő váltását tűzik ki az elérhető legkevesebb tranzienssel. Ez a meghatározó tulajdonság viszont még nem tekinthető definíciónak. Példaként tekintsük egy UNIX rendszer klasszikus felhasználói adatbázisát. Ez a legtöbb UNIX implementációban két fájlban testesül meg: a /etc/passwd tartalmazza a felhasználói fiókokat némi metainformációval, a /etc/shadow pedig a jelszavak hashelt változatát. Mindkét állomány sima szöveges és soronként egy rekordot tartalmaz. Csak fokozott elővigyázatossággal lehet őket szerkeszteni, mivel egyetlen hibás sor is megjósolhatatlan

12 Konfiguráció-menedzsment verziókövetett objektumokkal 12 működést eredményezhet, továbbá a két fájl egy-egy sora együttesen ír le egy felhasználói fiókot, ezért módosítások esetén a konzisztencia fenntartása nem triviális. Emiatt minden modern UNIX tartalmaz olyan segédprogramokat, melyekkel a felhasználói adatbázis közvetlen szerkesztés nélkül módosítható. Ilyen a szinte mindenhol elérhető useradd család. Ezek a parancssoros programok garantálják, hogy az adatbázis felhasználók által érzékelhető tranziensek nélkül módosítható. Ha a CM rendszerek fenti tulajdonságát tekintenénk definíciónak, akkor ez alapján a useradd család egy CM megoldás lenne. A gyakorlatban mégsem tekintik annak, mert nem skálázható egy számítógépnél többre, és hiányzik belőle sok olyan fejlett szolgáltatás, ami egy menedzsment megoldás igazi erejét adja. Az esetek többségében egy CM rendszernek része egy általános modellező környezet. Ez egy absztrakciós szintet ad a rendszer elképzelt modellje és a valódi konfiguráció között, ami lehetővé teszi az adminisztrátor számára, hogy modell szinten meghatározott összefüggések alapján dolgozzon. Így a tényleges konfigurációt ez a köztes réteg szolgáltatja, nem pedig valamilyen manuális beállítás. A modellezés jellemzően valamilyen speciális deklaratív nyelvvel történik. Visszatérve a UNIX felhasználói adatbázisának problémájára: egy felhasználó létrehozása a useradd segítségévél még megoldható magas szinten, viszont egy alias felvétele hagyományosan már csak kézzel, a /etc/aliases fájl szerkesztésével valósítható meg. Ha ezek után egy felhasználói fiókhoz tartozó bejelentkezési név megváltozik, azt két helyen kell módosítani: egyrészt a usermod használatával az adatbázisban, másrészt az előbb említett állományban. A CM például az ilyen jellegű helyzetekben nyújt informatikai támogatást, az emberi hibák és a tranziens jelenségek kiküszöbölésének érdekében. Egy CM rendszertől általában elvárhatóak még az alábbiak: változáskövetés A rendszer lehetőséget biztosít legalább a változások lekérdezésére, azaz az entitások élettörténetének megtekintésére. Fejlettebb rendszerek megvalósítják a rollbacket is, vagyis adott egy korábbi, helyesnek ítélt konfigurációra történő visszaállás lehetősége. öndokumentáló modell A konfigurációk absztrakt modellje felhasználóbarát leírását adja az elérhető állapotoknak.

13 Konfiguráció-menedzsment verziókövetett objektumokkal 13 biztonság A rendszerben tárolt konfigurációhoz a hozzáférés finoman szabályozott. Ez tipikusan Access Control List (ACL) segítségévél történik. validálás A rendszer garantálja, hogy a modellbe csak érvényes konfiguráció vihető fel. verifikáció A rendszer ellenőrzi, hogy a valódi konfiguráció a modellnek megfelelő-e. automatizmus A rendszer kevés ponton igényel felhasználói beavatkozást és legfeljebb annyira időigényes a használata, mintha minden beállítás kézzel történne. csoportmunka A rendszer támogatja a csoportos adminisztrációt és felkészítették a konkurrens módosítások kezelésére. A lista közel sem teljes egyes CM rendszerek többet, mások kevesebbet valósítanak meg a fentiekből. A legnagyobb nehézséget ilyen rendszerek vizsgálatakor mégis az jelenti, hogy a szempontok helyenként távolról sem objektívek. Egyetemes megoldás erre a problémakörre egyelőre nem létezik, és az elérhető rendszerek versenyeztetése csak élő, gyakorlati példához viszonyítva lehet releváns. Bár ez jelen dolgozat tárgyán túlmutat, lássuk milyen szolgáltatásokat ígér két nagyobb kereskedelmi CM rendszer. 2. IBM Tivoli platform Az IBM Tivoli megoldása egy olyan integrációs platform, amely hardver- és szoftverkonfigurációk, folyamatok és emberi tevékenységek menedzsmentjéhez nyújt nagyvállalati szintű infrastruktúrát. A termék komponenseinek megcélzott előnyei között szerepel az egységesített és átlátható adatmodell, illetve az erre építő automatizmusok beleértve a validálást és a verifikációt kialakításának támogatása. A Tivoli platform egyik sarokkövét képező Change and Configuration Management Database (CCMDB) az alábbi szolgáltatásokat biztosítja[2]: Elosztott konfigurációs adatbázis Az alapértelmezésben szállított, DB2 technológiára építő adatbázisháttér mellett lehetőség van egyedi konfigurációs adatbázis használatára.

14 Konfiguráció-menedzsment verziókövetett objektumokkal 14 Kiterjeszthető adatmodell A CCMDB képességei kiterjeszthetőek egyedi CI (configuration item), illetve attribútum elemekkel. Programozható felület Egy jól definiált API-n keresztül lekérdezhető és menedzselhető a konfiguráció. Erre építve egyedi igényeket kielégítő tooling is létrehozható. Intelligens jelentések A megoldás teljes mértékben testre szabható és áttekinthető jelentéskészítési funkciókkal bír. Konfigurálható munkafolyamatok Mélyebb szintű fejlesztési ismeretek nélkül is, fogd-és-vidd jellegű felületeken gyorsan leírhatóak vállalati munkafolyamatok. Audit napló A konfigurációk korábbi változatai összehasonlíthatóak, a CI élettörténetek megtekinthetőek. Integrációs pontok külső megoldásokhoz A rendszer mind az adat, mind a funkcionális szinten könnyedén integrálható külső szállító termékeihez. 3. BMC A BMC Configuration Manager integrált nagyvállalati megoldás az ismétlődő rendszergazdai feladatok automatizálására. Különleges szolgáltatásai az alábbiak[3]: Házirend-alapú menedzsment Az aktuális és a modellezett konfiguráció közötti eltérések folyamatos ellenőrzésével a verifikációs folyamatok önműködőek. Önműködő operációs rendszer migráció Automatikus, best-practice alapú frissítés és migrációs folyamatok jelemzik a rendszert. Szoftver-használati jelentések A vállalatban alkalmazott szoftverekről jelentések készülnek a licenszek megfelelő kihasználásának felmérése érdekében.

15 Konfiguráció-menedzsment verziókövetett objektumokkal 15 Patch-menedzsment megoldások A rendszer megoldást nyújt a hibajavításokat, frissítéseket tartalmazó patchek automatikus csomagolásához. Egységesített adminisztráció A termékfüggetlen, egységesített felületű telepítési és adminisztrációs segédprogramok elfedik a különböző külső szállítók termékeinek specialitásait. 4. Modellezési kihívások A fentiek alapján érezhető, hogy az adatmodell a CM esetén kulcsfontosságú. Egy túlzottan specifikus modell behatárolja a CM alkalmazhatóságának körét, ugyanakkor elengedhetetlen, hogy megkötéseket tartalmazzon, ellenkező esetben a validáció egyáltalán nem, vagy csak nagyon körülményesen oldható meg. Bizonyos modellezési eljárások természetükből adódóan nyújtanak megoldást az előzőekben ismertetett szempontokra, míg másokkal egyes pontok eleve megoldhatatlanok. A kályhától indulva vizsgáljunk meg négyet egy CM rendszer adatmodelljének lehetséges backendjei közül: XML alapú: a modell entitásai XML dokumentum formátumban kerülnek tárolásra. LDAP: a modell entitásai LDAP objektumok. RDBMS objektum-relációs leképezéssel: a modell entitásai egy OOP környezet objektumai, melyeket leképezzük egy rögzített relációs adatbázis sémába. Gyenge sémájú RDBMS: A modell entitásai egy OOP környezet objektumai, melyek a relációs adatbázis sémájának módosítása nélkül szabadon mutálhatók. A következőkben az alábbi kérdésekre keresünk választ a vázolt backend megoldások összehasonlítási alapjának meghatározása érdekében: Milyen formátumban kerülnek tárolásra az entitások? Hogyan azonosítja a backend az entitást? Hogyan tárolja az attribútumokat? Mennyire hatékony az adatszervezési eljárás? Van-e lehetőség ezen a szinten típusellenőrzésre, illetve ellenőrzött referenciák létrehozására? Milyen kommunikációs protokollon érhetőek el az adatok? A használt protokoll sima szöveges vagy bináris, illetve mennyire mondható ipari szabványnak? Eleve adott-e a titkosítás lehetősége, vagy ez csak egyedileg oldható meg?

16 Konfiguráció-menedzsment verziókövetett objektumokkal 16 A konfiguráció alkalmazási oldalról közvetlenül felhasználható, vagy generálni kell? Mennyire könnyű a séma kiterjesztése? Mit szükséges megváltoztatni annak érdekében, hogy egy entitás új attribútummal bővüljön? Megoldható-e ez a szolgáltatás megállítása nélkül? A backend az API-n túl milyen felületeken érhető el? Az adminisztrátornak milyen lehetőségei vannak az adatok közvetlen elérésére? Ezek a módszerek mennyire biztonságosak az adatintegritás szempontjából? Hogyan oldható meg a verziókövetés? Mennyire körülményes a változások folyamatos követése? Korábbi verzióra vissza lehete állni szolgáltatás-leállítás nélkül? Hogyan valósítható meg az adatvédelem? Van-e beépített megoldás az adatokhoz való hozzáférés szabályozására? Ha nincs, mennyire körülményes megvalósítani, és milyen fokú biztonság érhető el vele? Milyen a csoportmunka támogatás? Van-e lehetőség az entitások párhuzamos szerkesztésére? Mi történik konkurrens hozzáférés esetén? A megjósolható működéshez milyen zárolásokat használ a rendszer? Van-e tranzakciókezelés? 5. XML alapú modellezés Az első, talán legkézenfekvőbb megoldás az XML[4] (Extensible Markup Language) alapú modellezés. Tekintve, hogy a végcél tetszőleges konfigurációk előállítása, az XML egy természetes általánosítása a problémának. Ugyanakkor, mivel az XML önmagában pusztán egy fájlformátum, a hálózati elérés, a verziókövetés, és egy sor további fejlett szolgáltatás csak egy megfelelő kiszolgáló mellett lehetséges. A továbbiakban feltesszük, hogy ez adott, lévén, hogy egy XML szerver egy közönséges fájlkiszolgálóval megvalósítható. Az entitások tárolása ebben az esetben egy vagy több XML dokumentum formájában történik. Ha minden entitás külön dokumentum, az entitások azonosíthatóak egyszerűen a dokumentum mint erőforrás egyértelmű meghatározásával. Ellenkező esetben az entitást a tartalmazó dokumentum megjelölése mellett az azon belüli helye azonosítja, melyhez használható az XPath szabvány. Az attribútumok tárolása az XML strukturált felépítése miatt nem bonyolult, továbbá CDATA blokkok segítségévél és megfelelően megválasztott kódolás mellett elvileg tetszőleges értéket vehetnek fel.

17 Konfiguráció-menedzsment verziókövetett objektumokkal 17 Az adatszervezés hatékonysága megkérdőjelezhető. Legrosszabb esetben minden betöltött entitás külön fájlból származik, ami nagy bonyolultságú rendszereknél komoly teljesítménybeli problémákhoz vezethet. A megoldás ilyen értelemben vett ára elsősorban a használt fájlrendszertől, a fájlszerver gyorsaságától, az egyidejűleg használt objektumok számától és a párhuzamos elérés esetén fellépő zárolások számától függ. Típusellenőrzés ebben az esetben backend szinten akkor van, ha az XML dokumentumhoz tartozik előre definiált DTD (Document Type Definition). Ez az XML feldolgozást, ha lehet, még inkább lassítja. További probléma, hogy a DTD módosítása élő rendszerben előre nehezen látható következményekkel jár, ugyanis az ellenőrzés csak a dokumentum betöltésekor történik meg. Így elvileg elképzelhető, hogy a séma módosítása meglévő adatok érvénytelenítésével jár, és ami még rosszabb, ez csak az adatok későbbi felhasználásakor derül ki. Az XML szabvány lehetőséget nyújt referenciák elhelyezésére a dokumentumon belül, viszont ezeknek a feloldása az XML parser felelőssége, és a lehetőség valójában C-szerű terminológiával élve, inkább a makrókra hasonlít. Dokumentumokon átívelő referenciák használatára nincs lehetőség, így általánosságban erre a kérdésre csak alkalmazásszintű válasz adható. A kommunikációs protokoll a használt fájlszervertől függ. Szolgáltatásokban gazdag megoldás érhető el egy alkalmasan megválasztott WebDAV kiszolgálóval. A DAV (Distributed Authoring and Versioning) az ipari szabványnak tekinthető, sima szöveges HTTP protokoll kiterjesztett utasításkészletű változata, amely gond nélkül használható SSL-lel titkosított csatornán is. A konfigurálandó alkalmazások sajnos a legritkább esetben támogatják a beállítások WebDAV szerverről történő letöltését. Ez igaz a többi klasszikus fájlmegosztó szolgáltatásra is, ezért az XML alapú modellezés általános esetben megköveteli a konfiguráció generálását és offline használatát. Az XML létrehozásakor tervezési döntés volt a sima szöveges formátum, így a dokumentumok akár tetszőleges szövegszerkesztővel vagy specifikus segédprogrammal megtekinthetők és szerkeszthetők. Azonban a dokumentumok felépítése elsősorban a CM rendszer igényeit szolgálja, és ebből adódóan a CM rendszer mélyebb ismerete nélkül az XML dokumentumok közvetlen szerkesztése nem csak nehézkes, de adatintegritási szempontból veszélyes művelet is lehet. A verziókövetés lehetősége és az ehhez kapcsolódó szolgáltatások szintén szerverfüggők. A fájlszerver használhat verziókövető fájlrendszert, ennek szolgáltatásai viszont alkalmazási

18 Konfiguráció-menedzsment verziókövetett objektumokkal 18 oldalról csak nehezen és az esetek többségében komoly biztonsági problémákat felvetve vehetők igénybe. Például a jelenleg elérhető implementációkkal WebDAV használata mellett sem lehet a protokoll verziókövető funkcióit kihasználni. Az, hogy a szerver mögött egy verziókövető motor gondoskodik a változások követéséről, pusztán a szerveren adminisztratív privilégiumokkal rendelkező felhasználók életét segíti, a korábbi verziók megtekintése és visszaállítása csak számukra elérhető. Az adatok védelme fájlrendszerszintű jogosultságkezeléssel, nagy biztonsággal megvalósítható. Szervertől függően szóba jöhet a klasszikus UNIX-os hármas jogosultságrendszer vagy a POSIX ACL-ek is. A csoportmunka támogatás a választott fájlszerver lehetőségeiből következik. Ha a szerver támogatja a fájlzárolást, a konkurrens hozzáférés megvalósítható, viszont több állomány kezelése mellett ez könnyen dead-lock-hoz vezethet. Ami leginkább megkérdőjelezi a többfelhasználós üzemmódot, az a tranzakciók teljes hiánya, pontosabban, hogy azok kezelése az alkalmazás felelősségi körébe tartozik. 6. LDAP alapú modellezés Az LDAP[5] (Lightweight Directory Access Protocol) a címtárszolgáltást biztosító protokollok legnépszerűbb szabványa. Sokkal többet nyújt a hagyományos telefonkönyvszerű szolgáltatásoknál, melyet mi sem bizonyít jobban, mint hogy a Microsoft Windows Serverek Active Directory[6] nevű megoldása LDAP alapú. Az említetten kívül minden nagyobb informatikai szállító rendelkezik saját LDAP implementációval, a Sun Microsystems-től az Oracle-ig. Az LDAP adatbázis fastruktúrában tárolt objektumok halmaza. Fontos hangsúlyozni, hogy a legtöbb LDAP implementáció nem alkalmazásszerver, és az objektumokhoz egyéni műveletek adatbázisszinten nem társíthatóak. Az objektumok egy előre rögzített sémának megfelelő attribútumokat tartalmazó entitások. Azonosítójuk az ún. DN (distinguished name), amely a fa gyökeréből kiindulva az objektumhoz vezető egyértelmű elérési út. Az LDAP szervereket tipikusan keresésre és olvasásra optimalizálják, egyéb műveletekre jellemzően rosszabbul teljesítenek, mint a relációs adatbázisok. Ez konfiguráció tárolása esetén nem feltétlenül jelent gondot, mivel a problémakör természeténél fogva a műveletek döntő többsége olvasás. A legtöbb LDAP szerver legalább read-only replikák felállításának lehetőségével erősíti a skálázhatóságot.

19 Konfiguráció-menedzsment verziókövetett objektumokkal 19 A típusellenőrzés előre rögzített sémával adatbázisszinten megoldható. A sémában értelmezett az öröklődés, aminek köszönhetően átláthatóan leírható egy objektum attribútumainak halmaza. Az attribútumok lehetnek többértékűek, és tárolhatnak bináris értéket is. Az LDAP fa egyes elemei hivatkozhatnak más objektumokra. Nem minden LDAP szerver támogatja a séma dinamikus frissítését. Az LDAP egy széles körben támogatott bináris protokoll, melynek létezik SSL-el védett változata (LDAPS). Nagyszámú programnyelvhez elérhető megbízható, kliensoldali API, ezért a legtöbb nyílt forrású szerveralkalmazás támogatja a konfiguráció LDAP szerverről történő, dinamikus lekérdezését. Jó példa erre az Apache webszerver, a Postfix SMTP szerver vagy a Bind9 DNS kiszolgáló. Számos jól használható LDAP kliens létezik, amik közül vannak, melyek webes felületet is adnak egy LDAP adatbázis közvetlen eléréséhez. Ezekkel az adatbázis kényelmesen és adatintegritási szempontból biztonságosan szerkeszthető. Verziókövetésre egyetlen nagyobb LDAP szerver sem nyújt támogatást. A változások lekérdezése és visszaállítása integrált módon nem megvalósítható. Mivel az LDAP szabványban definált LDIF (LDAP Interchange Format) sima szöveges dumpját képezi az adatbázisnak, az erről készült rendszeres pillanatképekkel követhetőek a verziók, ez viszont csak a probléma megkerülése; a változások rögzítése így nem folyamatos, a szerver adminisztrátorának kézi beavatkozása szükséges, és a visszaállítás szolgáltatáskimaradással jár. Az LDAP szerverek jellemzően egy nagyon fejlett biztonsági modellt valósítanak meg. Akár attribútumszinten is korlátozható a hozzáférés az objektumokhoz. Többek közt ezért is népszerű az LDAP a központi felhasználó-menedzsment megoldásokban, ahol a felhasználói fiókok LDAP objektumokként tárolódnak, és azok bizonyos attribútumai akár a felhasználó által is szerkeszthetők (pl. a jelszó), mások pedig akár rejtettek is lehetnek megfelelő privilégiumok nélkül. A többfelhasználós üzemmód korlátokkal támogatott. Az LDAP nem tartalmaz tranzakciókezelő utasításokat, így az adatbázison végzett műveletek egyik implementációban sem izolálhatóak. Ez komoly gondot jelenthet a konkurens hozzáférések kezelésében, ha ugyanazon logikai művelet több objektum módosításával jár.

20 Konfiguráció-menedzsment verziókövetett objektumokkal Objektum-relációs leképezés Ennek a modellezési eljárásnak a lényege, hogy a CM rendszer objektumait még tervezési fázisban leképezzük egy relációs adatbázisháttérre. A leképezés lehet dinamikus olyan értelemben, hogy az objektumok egyfajta leírásából automatikusan generálódik mind a relációs séma, mind az azt használó programkódnak egy része, végeredményben viszont a séma az adatbázisban rögzített lesz és nem frissíthető a kód módosítása nélkül. Az objektumok azonosításának módszere a leképezést végző szoftver megvalósításától függ. A legtöbb esetben az azonosítót természetes módon az objektum osztályát jelképező tábla elsődleges kulcsa adja. Az attribútumok tipikusan az ezen kulccsal jelölt rekord további mezői. Többértékű attribútumok implementációja külső táblában történő tárolással lehetséges. A típusok ez esetben szigorú SQL típusok, melyek adatbázisszinten ellenőrzöttek. A referenciák idegen kulcsként jelentkeznek az adatmodellben, melyek integritásáról szintén az adatbáziskezelő gondoskodik. A relációs adatbáziskezelők az előző két megoldással szemben mind az olvasásra, mind az írásra jól optimalizáltak, ezért egy gondosan megtervezett objektummodellt feltételezve az optimálist megközelítő teljesítmény érhető el. A legtöbb SQL szerver továbbá beépített megoldást nyújt clusterek kialakítására, és így a skálázhatóság csak milliós nagyságrendű objektumszám mellett jelent sématervezési kihívást. A relációs adatbáziskezelők egytől-egyig saját, jellemzően bináris protokollon érhetőek el, amely SSL-lel tehető biztonságossá. Bár ezek mind különbözőek, alkalmazási oldalról minden programozási nyelv alatt elérhető valamilyen szabványos adatelérési könyvtár C/C++ alatt az ODBC, Java alatt a JDBC, Perl alatt a DBI aminek köszönhetően a különböző adatbáziskezelők azonos API-n keresztül használhatóak. Ezért sok nyílt forráskódú szerveralkalmazás (az LDAP mellett) relációs adatbáziskezelőből történő dinamikus konfigurálást is támogat. A séma kiterjesztése, mint az a korábbiakban említésre került, nem lehetséges a kód és az adatbázis együttes módosítása nélkül. Ahhoz, hogy ez éles rendszeren leállítás nélkül végbemenjen, gondosan tervezett migrálás szükséges. Egy új attribútum felvétele tehát nem kivitelezhetetlen, de nem is tekinthető mindennapi rutinfeladatnak. Az adatbázis közvetlen szerkesztésére a legtöbb RDBMS egy SQL konzolt nyújt. Ezzel mind a séma, mind az adatok szabadon lekérdezhetőek és szerkeszthetőek. A CM rendszer alapos

21 Konfiguráció-menedzsment verziókövetett objektumokkal 21 ismerete szükséges ahhoz, hogy ez ne vezessen adatintegritási problémákhoz. A verziókövetésre az adatbázisszerverek nem nyújtanak támogatást, mivel ez nem képezi egyik SQL szabvány részét sem. Így a változatok követése vagy része az objektummodellnek, és ebből adódóan az alkalmazás felelőssége a verziókezelés, vagy az LDAP-ról elmondottak érvényesek ez esetben is. Azaz, az adatbázisról készülhet egy sima szöveges SQL nyelvű dump, amelynek manuális verziókövetését végezheti az adminisztrátor. Az adatvédelem a legtöbb SQL szerverben tábla szintű jogosultságkezeléssel valósítható meg. Ez meglehetősen szegényes biztonsági házirendhez vezetne, ezért komolyabb alkalmazások egyszerűen megtiltják az adatbázis közvetlen elérését, és egyedileg gondoskodnak a hozzáférésszabályozásról. Nem ritka az sem, hogy egy alkalmazás a felhasználók azonosításához és hitelesítéséhez egy másik külső adatforrást (pl. egy LDAP szervert) vesz igénybe. A csoportmunka támogatás SQL szerverek esetén a legkiemelkedőbb. ACID jellegű tranzakciók és ebből következően írásra és olvasásra egyaránt valódi többfelhasználós üzemmód a jellemző. A zárolások megvalósítása szerverenként különböző, de bizonyos esetekben elérhető a sor szintű locking is. 8. Gyenge sémájú relációs modellezés Jelen dolgozat gyenge sémájúként hivatkozik arra a relációs adatbázisra, amely a lehetséges entitásokat és azok attribútumainak halmazát nem írja elő, valamint az attribútumok típusait séma szinten nem kényszeríti ki. A megoldás bizonyos értelemben magasabb szabadságfokkal bír az objektum-relációs leképezéshez képest, aminek a nem titkolt árát teljesítményben fizeti meg. Ez a megközelítés röviden összefoglalva egy olyan sémát használ, amely az adatmodell metamodelljét rögzíti. Leegyszerűsítve az entitás és az attribútumok közötti 1-n kapcsolat reprezentálása egy-egy táblával történik. Így az objektum azonosítója az első tábla elsődleges kulcsa, az attribútumok táblája pedig ezt, mint idegen kulcsot használja. Ebből adódóan típusok csak különböző attribútumtáblákkal, vagy ugyanazon táblában tárolt redundáns mezőkkel valósíthatók meg. A referenciák ettől függetlenül idegen kulcsok segítségével lehetnek ellenőrzöttek. A módszer nagy előnye a rugalmas modell, amely éles üzem mellett szabadon módosítható, ami gyengén típusos, dinamikus programozási környezetkben jól kihasználható. Látható viszont

22 Konfiguráció-menedzsment verziókövetett objektumokkal 22 az is, hogy egy objektum lekérdezése legalább 1 JOIN művelet nélkül nem lehetséges, ami teljesítménykorlátokat hordoz magában. Ezen meghatározó különbségtől eltekintve az előző alfejezetben említettek itt is érvényesek.

23 Konfiguráció-menedzsment verziókövetett objektumokkal CM modellezési eljárások összehasonlítása XML LDAP RDBMS (ORM) RDBMS (gyenge séma) Entitások tárolása fájlrendszerben adatbázisban adatbázisban adatbázisban Attribútum típusok Referenciák Hálózati protokoll egyedi, pl. WebDAV LDAP egyedi egyedi SSL támogatás + (ha támogatott) Séma módosítás adatintegritásra veszélyes újraindítást igényel újrafordítást igényel szabadon (nincs séma) Dinamikus konfiguráció Generált konfiguráció Olvasási sebesség Írási sebesség Közvetlen elérés fájlok szerkesztése LDAP kliens SQL konzol SQL konzol Verziókövetés (ha implementált) + (ha implementált) Jogosultságkezelés fájlrendszer szintű attribútum szintű tábla szintű - Tranzakciókezelés Zárak fájl szintű (ha támogatott) - rekord szintű rekord szintű

24 Konfiguráció-menedzsment verziókövetett objektumokkal 24 IV. Adatmodell gyenge sémájú modellezéshez Mottó: Különböző filozófiájú technológiák házasítása egyszerre egyesítheti azok minden jó és rossz tulajdonságát. 1. Az adatmodell követelményei Jelen dolgozat egyik célja egy egyedi CM rendszerben felhasználható adatmodell megtervezése[7]. Az előző fejezetben említett módszerek közül a választás a gyenge sémájú modellezésre esett, melyre megszorításokkal ugyan, de kijelenthető, hogy egy gondosan implementált keretrendszer mellett a gyengén típusos környezetek rugalmasságát ötvözi a relációs adatbáziskezelők teljesítményével. A gyenge sémájú modellezésből származó előnyöket értelemszerűen csak egy gyengén típusos, dinamikus programozási környezetben lehet kamatoztatni. Ezen programozási környezetek közül sok vagy eleve objektum-orientált szemléletű (pl. Python, Ruby), vagy legalábbis kényelmesen alkalmazhatóak bennük az OOP paradigmák (pl. Perl). Egy CM megoldás entitásai természetes módon képezhetők le egy objektum rendszerre, tekintve a valós élet objektumaival vett kapcsolatukat: egy felhasználói fiók egy objektum, amelyen értelmes művelet a bejelentkezési név megváltoztatása. További példák az OOP és a CM kapcsolatára: adatrejtés UNIX alatt a /etc/passwd fájl rekordjai sorokba rendezettek, és a sorokon belül a mezőhatároló karakter a ':'. Ha ezzel a részletkérdéssel a felhasználói kvótákról jelentést készítő programkód nem kell, hogy foglalkozzon, az nem csak átláthatóbb, de jobban újrafelhasználható megoldást eredményez. öröklődés Egy webszerver és egy szerver is egy hálózati kiszolgáló mindkettőn értelmes művelet az indításuk előtt az általuk használt port foglaltságának ellenőrzése. polimorfizmus Egy webszervert és egy szervert jelképező objektum start metódusa azonos programozói felületet kíván, viszont a műveletek megvalósítása természetesen különbözhet.

25 Konfiguráció-menedzsment verziókövetett objektumokkal 25 A tervezendő adatmodelltől azt várjuk, hogy jól illeszkedjen egy gyengén típusos objektumorientált környezethez. Támogatnia kell az objektum és a műveleteit implementáló osztály összerendelését, a referenciákat, és valamilyen objektum-hierarchiát. Ezeken kívül a következő igényeket támasztjuk a fejlettebb szolgáltatások kialakításához: objektumfa Az objektumok fastruktúrában tárolódjanak és ugyanazon objektum a fa több csúcspontjához legyen linkelhető. verziókövetés Az objektumok és attribútumaik legyenek verziókövetés alatt. Legyen lehetőség egy objektum korábbi állapotának megtekintésére ez adatmodell szinten csak az adattagokra garantálható, a metódusok implementációiban keletkezett változtatásokra nem érvényes. auditálás Legyen nyomon követhető az adatbázison végzett műveletek listája, időbélyeggel ellátott műveleti napló segítségével. 2. Entitás-relációk tervezése Mint az a korábbiakban említésre került, a gyenge sémájú modellezés alapötlete a metamodell implementálása a végleges adatmodell helyett. Ez a következő leegyszerűsített kapcsolatot feltételezi: Objektum tartalmaz Attribútum Az attribútumok mindig kulcs-érték párok, függetlenül attól, hogy az érték adott esetben egy egyszerű szám, vagy további objektumok kollekciója. A kulcsokat és az értékeket önálló entitásként ábrázolva a következő modellhez jutunk:

26 Konfiguráció-menedzsment verziókövetett objektumokkal 26 Kulcs Objektum attribútum Érték Ez az elképzelés egyszerűsége mellett számos pozitív lehetőséget hordoz magában. A verziókövetés megvalósítása az entitás-relációk érintése nélkül implementálható, ha az Objektum entitásra, mint az objektum egy verziójára tekintünk. Ehhez mindössze arra van szükség, hogy a nevezett entitás azonosítóját az objektum azonosítója és a verziószám összetett kulcsként adja. A modellben akár a kulcsok neveinek, akár az értékeknek a változatlansága természetszerűleg leírható, amivel a redundancia elfogadható szintre csökkenthető. A fenti Objektum entitást a valódi objektum egy változataként kezelve felmerül a kérdés, hogy ha egy attribútum értéke egy másik objektum referenciája, akkor a hivatkozás tartalmazza-e a verziószámot. Azaz, amikor egy objektum tartalmazza egy másik referenciáját, azzal egy konkrét, rögzített verzióra hivatkozik vagy annak a legfrissebb állapotára. Az első megközelítésből kiindulva a modell nem veszít általánosságából, és leírhatóak vele olyan különleges esetek is, amikor egy attribútumérték egy időközben frissült objektum régebbi verziójával dolgozik. Ez egy további problémát vet fel. A műveletek nem az adatbázisban tárolódnak, és mivel így nem állnak verziókövetés alatt, a metódusokat megvalósító osztályoknak visszafele kompatibilisnek kellene lenniük minden olyan objektumverzióra, amelyre létezik referencia. A második megközelítés, azon túl, hogy lemond a régebbi objektumok hivatkozásának lehetőségéről, egy kényelmesebben kezelhető adatszerkezetet nyújt. Ha egy objektum frissül, nem szükséges az összes rá hivatkozó objektumot frissíteni annak érdekében, hogy az új változat elérhetővé váljon. Ez a viselkedés programozói szemmel sokkal inkább nevezhető elvártnak az előzőhöz képest.

27 Konfiguráció-menedzsment verziókövetett objektumokkal 27 Az objektumok fába rendezése egy hasonló, de talán még nehezebben megválaszolható tervezői döntés kérdését veti fel. A fa lehet önmagában verziókövetett, azaz működhet egy modern verziókövető rendszer könyvtárstruktúra-kezelésének mintájára. A másik lehetőség, hogy a fa nem követi a változásokat, csak objektumreferenciákat tartalmaz, ami további két opcióként ismét vonatkozhat az objektum verziójára vagy magára az objektumra. A fa verziókövetése akkor valósítható meg, ha létezik egy globális verziószám a teljes fastruktúrára, és ezt a verziószámot használják az abban szereplő objektumok. Ez azzal járna, hogy a rendszerben lévő bármely objektum bármely attribútumán történő változtatás az objektumrendszer egészének egy új verzióját eredményezné, amit ezen a ponton önkényes választás alapján elkerülünk. A fa tehát nem verziókövetett, és az attribútumértékeknél kifejtett indokok miatt a benne tárolt referenciák objektumokat címeznek és nem verziókat. Mindezt összefoglalva az alábbi ER-diagram adja az objektummodellt: gyermeke Objektum tartalmaz Kulcs Objektum verzió attribútum Érték

28 Konfiguráció-menedzsment verziókövetett objektumokkal Relációs séma tervezése Mielőtt a bemutatott entitás-relációk alapján relációs adatbázisban felhasználható séma készülhetne, a modell még egy kis kiegészítésre szorul. Egyrészt nem esett szó még az audit log megvalósításáról. Erre egy külön tábla fog szolgálni, a modelltől valamilyen szinten függetlenül, kizárólag naplózási célra. Másrészt a modell objektumai bár gyengén típusos környezetben fognak CM célokat szolgálni minden esetben tartalmaznak legalább olyan szintű típusinformációt, hogy a műveletek megvalósításai milyen osztályban vagy csomagban keresendők, illetve mi az a befoglaló adatszerkezet, amelyen keresztül a kulcs-érték párok elérhetőek. Ez nyelvspecifikus kérdés, az adott programozási környezet határozza meg ezeknek a tulajdonságoknak a lehetséges értékeit. Itt ismét önkényesen a modellt úgy alakítjuk, hogy az típusosság szempontjából a Perl programozási nyelvnek kedvezzen. A későbbiekben még szó esik a Perl és az OOP kapcsolatáról, egyelőre fogadjuk el, hogy a tervezett rendszer objektumai egy csomagnévvel azonosított osztályból veszik a metódusaikat, és az adataikat egy tetszőleges méretű skalár, tömb vagy asszociatív tömb írja le. A relációs séma tábláit és azok jelentésék a következő alfejezetek tárgyalják. Mivel a fejlesztés MySQL[8] adatbáziskezelővel történt, a táblák DDL leírásai ezen RDBMS SQL dialektusát tükrözik. A mellékelt diagramon vastag betűvel szedettek azok a mezők, amelyek nem vehetnek fel NULL értéket. Az elsődleges kulcsokat a kulcs szimbólum jelzi, összetett kulcsok esetén értelemszerűen több mezőt jelölve. A nyilak az idegen kulcsokat jelentik, egy táblából akkor mutat nyíl egy másikra, ha az első idegen kulcsként használja a második tábla valamely mezőjét.

29 Konfiguráció-menedzsment verziókövetett objektumokkal 29

30 Konfiguráció-menedzsment verziókövetett objektumokkal ActLog tábla Az ActLog (Action Log) tábla az audit logot hivatott megvalósítani. Minden rekordja egy adott időpillanatban egy objektumon végrehajtott műveletet naplóz. Kényszerként nem tartalmaz idegen kulcsokat annak érdekében, hogy az objektumok a naplóbejegyzések érvénytelenítése nélkül törölhetőek legyenek. act_ts obj_id role action TIMESTAMP típusú mező a művelet időbélyegének leírásása. INT típusú mező a művelet tárgyát jelentő objektum azonosításához. Az act_ts mezővel együtt elsődleges kulcsa a táblának. VARCHAR típusú mező a műveletet végző szerepkör azonosítására. Ez tartalmazhatja például annak a felhasználónak a belépési nevét, aki az adatbázison dolgozó szkriptet futtatja. comment VARCHAR típusú mező a művelet leírásása. TEXT típusú mező a szabadszöveges megjegyzések tárolásához. CREATE TABLE `ActLog` ( `act_ts` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, `obj_id` int(11) NOT NULL, `role` varchar(128) NOT NULL, `action` varchar(128) NOT NULL, `comment` text, PRIMARY KEY (`act_ts`,`obj_id`), KEY `ActLog_role` (`role`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 5. ObjTree tábla Az ObjTree (Object Tree) tábla az objektumfát valósítja meg. Minden rekordja a fa egy csúcspontja. Az objektumok névvel azonosítottak, és a fában teljes elérési útjuk alapján találhatóak meg.

31 Konfiguráció-menedzsment verziókövetett objektumokkal 31 name parent obj_id VARCHAR típusú mező, az objektum nevét tartalmazza. INT típusú mező, az objektum szülőjének azonosítóját tartalmazza. Idegen kulcs ugyanezen tábla obj_id mezőjére. A name mezővel együtt elsődleges kulcsa a táblának. INT típusú mező az objektum azonosítójának tárolására. CREATE TABLE `ObjTree` ( `name` varchar(128) NOT NULL default '', `parent` int(11) NOT NULL default '1', `obj_id` int(11) NOT NULL auto_increment, PRIMARY KEY (`name`,`parent`), KEY `Object_ID` (`obj_id`), KEY `Parent object must exist` (`parent`), CONSTRAINT `Parent object must exist` FOREIGN KEY (`parent`) REFERENCES `ObjTree` (`obj_id`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 6. ObjRev tábla Az ObjRev (Object Revision) tábla az objektumok verzióit tárolja. Minden rekordja egy adott objektum verzióját jelképezi. obj_id obj_rev type_id INT típusú mező az objektum azonosítójának tárolására. Idegen kulcs az ObjTree tábla azonos nevű mezőjére. INT típusú mező, az objektum verziószámát tartalmazza. Az obj_id mezővel együtt a tábla elsődleges kulcsa. INT típusú mező, az objektum típusát leíró ObjType rekord idegen kulcsa. CREATE TABLE `ObjRev` ( `obj_id` int(11) NOT NULL, `obj_rev` int(11) NOT NULL default '0', `type_id` int(11) NOT NULL, PRIMARY KEY (`obj_id`,`obj_rev`), UNIQUE KEY `obj_id` (`obj_id`,`obj_rev`), KEY `Object_type` (`type_id`), CONSTRAINT `Object must exist` FOREIGN KEY (`obj_id`) REFERENCES `ObjTree` (`obj_id`) ON DELETE CASCADE,

32 Konfiguráció-menedzsment verziókövetett objektumokkal 32 CONSTRAINT `Type must exist` FOREIGN KEY (`type_id`) REFERENCES `ObjType` (`type_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 7. ObjType tábla Az ObjType (Object Type) tábla az objektumok típusának leírására szolgál. Minden rekordja egy típusdefiníció. type_id class tie INT típusú mező, a típus egyértelmű azonosítója, a tábla elsődleges kulcsa. INT típusú mező, az objektum osztályát tartalmazó csomag jelölésére szolgál. A csomag nevét a rendszer egy másik objektumának value nevű attribútuma adja, ezért ez a mező az ObjTree tábla obj_id mezőjére hivatkozó idegen kulcs. Ha ez a mező NULL, akkor az objektum a tie mezőben tárolt információ alapján egy alapértelmezett osztály példánya lesz. ENUM típusú mező, amely azt az adattípust jelöli, amelyen keresztül később az objektum attribútumai elérhetőek lesznek. Ha ez SCALAR, az objektum value nevű attribútuma adja a skalár értékét, ha pedig ARRAY vagy HASH, akkor az attribútum kulcs-érték párjai a megfelelő tömbszerkezet kulcsához tartozó értékek lesznek. CREATE TABLE `ObjType` ( `type_id` int(11) NOT NULL auto_increment, `class` int(11) default NULL, `tie` enum('scalar','array','hash') NOT NULL default 'HASH', PRIMARY KEY (`type_id`), KEY `Object_class` (`class`), CONSTRAINT `Object class must exist` FOREIGN KEY (`class`) REFERENCES `ObjTree` (`obj_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 8. ObjAttr tábla Az ObjAttr (Object Attribute) tábla az objektumok attribútumainak kapcsolótáblája. Minden rekordja egy attribútumot jelképez. obj_id INT típusú mező az objektum azonosítójának tárolására.

33 Konfiguráció-menedzsment verziókövetett objektumokkal 33 obj_rev INT típusú mező az objektum verziószámának tárolására. Az obj_id mezővel együtt idegen kulcs az ObjRev tábla azonos nevű mezőire. attrkey_id INT típusú mező az attribútum kulcsának jelölésére. Idegen kulcs az AttrKey tábla azonos nevű mezőjére, továbbá az obj_id és obj_rev mezőkkel együtt képezi a tábla elsődleges kulcsát. attrval_id INT típusú mező az attribútum értékenek jelölésére. Idegen kulcs az AttrVal tábla azonos nevű mezőjére. Ha a mező NULL, az azt jelenti, hogy az objektum attribútumát törölték. CREATE TABLE `ObjRev` ( `obj_id` int(11) NOT NULL, `obj_rev` int(11) NOT NULL default '0', `type_id` int(11) NOT NULL, PRIMARY KEY (`obj_id`,`obj_rev`), UNIQUE KEY `obj_id` (`obj_id`,`obj_rev`), KEY `Object_type` (`type_id`), CONSTRAINT `Object must exist` FOREIGN KEY (`obj_id`) REFERENCES `ObjTree` (`obj_id`) ON DELETE CASCADE, CONSTRAINT `Type must exist` FOREIGN KEY (`type_id`) REFERENCES `ObjType` (`type_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 9. AttrKey tábla Az AttrKey (Attribute Key) tábla az attribútumok kulcsát tartalmazza. Minden rekordja egy névvel ellátott kulcs. attrkey_id INT típusú mező az attribútumkulcs egyértelmű azonosítására, a tábla elsődleges kulcsa. attr_key VARCHAR típusú mező, az attribútum nevét tartalmazza. CREATE TABLE `AttrKey` ( `attrkey_id` int(11) NOT NULL auto_increment, `attr_key` varchar(128) NOT NULL, PRIMARY KEY (`attrkey_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

34 Konfiguráció-menedzsment verziókövetett objektumokkal AttrVal tábla Az AttrVal (Attribute Value) tábla az attribútumok értékét tartalmazza. Minden rekordja egy gyenge típusú érték. attrval_id INT típusú mező az attribútum értékének egyértelmű azonosítására, a tábla elsődleges kulcsa. attr_type ENUM típusú mező az attribútum gyenge típusának meghatározására. Ennek jelentését a későbbiekben tárgyaljuk, a lehetséges értékek: string, delegate és object. Értéke befolyásolja, hogy a további mezők közül melyik szolgáltatja az attribútum értékét. attr_ref INT típusú mező objektum-referencia tárolására. Idegen kulcs az ObjTree tábla obj_id nevű mezőjére. Ha az attr_type értéke delegate vagy object, ez a referencia számít az attribútum értékének meghatározásakor. attr_val BLOB típusú mező egyszerű értékek tárolására. Ha az attr_type értéke string, ez a referencia számít az attribútum értékének meghatározásakor. Az adatbázisban nem tárolt integritási feltétel, hogy az attr_ref és az attr_val mezők közül legfeljebb az egyik vehet fel nem NULL értéket, és a nem NULL értékű mezőt az attr_type jelzi. CREATE TABLE `AttrVal` ( `attrval_id` int(11) NOT NULL auto_increment, `attr_type` enum('string','delegate','object') NOT NULL default 'string', `attr_ref` int(11) default NULL, `attr_val` blob, PRIMARY KEY (`attrval_id`), KEY `AttrVal_ref` (`attr_ref`), CONSTRAINT `Reference must exist` FOREIGN KEY (`attr_ref`) REFERENCES `ObjTree` (`obj_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

35 Konfiguráció-menedzsment verziókövetett objektumokkal 35 V. A Perl nyelv Mottó: A könnyű dolgok legyenek egyszerűek, a nehezebb dolgok pedig megvalósíthatóak. Larry Wall 1. A nyelv eredete A Perl[9] egy általános célú, C-szerű szintaktikával bíró dinamikus, interpretált programozási nyelv, melyet 1987-ben hozott létre az akkor a NASA-nál rendszeradminisztrátorként dolgozó Larry Wall. Eredetileg a ksh-sed-awk klasszikus UNIX-os hármas kiváltására született, elsősorban a mindennapi adminisztrátori feladatok, ezek közül is a riportkészítés egyszerűbbé tétele érdekében. Azóta a nyelv számos verziót megélt, melyek közül a legfontosabb mérföldkő az 1994-ben bemutatott Perl 5. Ebben a változatban jelentek meg azok a fejlett nyelvi elemek, melyek nélkül a Perl a gyakorlatban nehezen volna használható kisebb szkriptelési feladatokon kívül bármire is; így a referenciák, az objektumok, vagy a modulok kezelése mind a Perl 5 sajátja. Ma a Perl egyike a legsikeresebb dinamikus nyelveknek. Elsősorban UNIX adminisztrátorok körében népszerű, de a bioinformatikától a webprogramozásig számos helyen alkalmazzák. Elterjedtségét többek között korlátlan rugalmasságának és a rapid alkalmazásfejlesztés támogatásának köszönheti, továbbá annak a ténynek, hogy a Perl modulok hivatalos gyűjtőhelye, a CPAN[10] az írás pillanatában több, mint modult tartalmaz, melyek a jelenlegi stabil 5.10-es változathoz ingyenesen elérhetőek. A Perl megalkotója, Larry Wall eredeti foglalkozása szerint nyelvész, és talán nem véletlen, hogy a programnyelv filozófiáját tekintve sok közös vonást mutat a természetes nyelvekkel. Pl. nem szükségszerű a nyelvet teljes egészében ismerni ahhoz, hogy valaki elkezdjen vele foglalkozni ugyanúgy, ahogy bizonyos helyzetekben egy angolul társalgási szinten tudó is elboldogul, és nem szükséges felsőfokú nyelvvizsga ahhoz, hogy valaki egy étteremben rendeljen egy steaket. Ez a tulajdonság tette egyszerre híressé és hírhedté a nyelvet. Viszonylag könnyű beletanulni, viszont már a legalapvetőbb programozási feladatokat is rendkívül sokféle módon lehet benne megvalósítani. Ez egy nagyobb projekt esetén megnehezítheti egy programozó csapat feladatát akkor, ha a csapat tagjai különböző szinten beszélik a Perlt, és nincsenek szigorú kódolási