Rendszerintegráció vizsgakérdések 2008 tavasz

Ez az oldal a korábbi SCH wikiről lett áthozva.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor, kérlek, javíts rajta egy rövid szerkesztéssel!

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót.

A hivatkozott anyagok lelőhelye: http://www.iit.bme.hu/~szebi/rinteg.html

X400 - funkcionális és architekturális modell. Naming és addressing. ASN.1 szerep és jelentõsége.

• x400.ppt
• Message Transfer System: Message Transfer Agents
• Message Handling System: User Agents + MTS; Message Store, Access Unit
• DirectoryService
• Abstract Syntax Notation: precise, formal notation that describes data structures for representing, encoding, transmitting, and decoding data

X400 - IPM és EDI. Felhasználási területek. X400/IPM és SMTP összehasonlítása.

• x400.ppt
• InterPersonal Messaging: between User Agents
• Electronic Data Interchange: computer-computer communication over Value Added Network
• Simple Mail Transfer Protocol: multiple clients, one server, textual (HELO/MAIL FROM/RCPT TO/DATA/QUIT)

MIME - kialakítása. Típusok és kódolások. MIME és X400 kódolás összehasonlítása. Ékezet az email "Tárgy" mezõben.

• mime.ppt

CGI - HTTP protokoll elemek. A cgi-scriptek mûködése. Scriptek felépítése. Lehetséges-e állapotprogramozás?

• cgiservlet.ppt

servlet - lényege, életciklusa, kialakítása. doXXX metódusok és szerepük.

• cgiservlet.ppt

servlet - MVC tervezési minta. JSP lényege. Formai kialakítása. Taglib. Mi a JSTL?

• cgiservlet.ppt

servlet - Beanek. Bean használata, kialakítása. Beanek hatósugara. A "session" változó. Állapotprogramozás.

• cgiservlet.ppt

Servlet-framework lényege, használati módjaik. Ismertebb framework-ök.

• spring_introduction.pdf
• You can create a servlet framework by assigning responsibilities to various system components
• reflection
• Spring

CSS - alapelvek. Szabályok szerkesztése. Öröklõdés. Kaszkádolás. DIV és SPAN szerepe. CSS szerepe az XML-ben.

• css.ppt

XML - szintaxis. Hogyan alakult ki az XML, melyek a legfontosabb jellemzõi? Elemek és jellemzõk. DTD szerepe, kialakítása. Bonyolultabb szerkezetek a DTD-ben. DOM és SAX.

• xml1.ppt

Hogyan lehet az XML-t alkalmazni rendszerek közötti átvitelre (XML-API)? Milyen az XML belsõ szerkezete? Mi az XPath és hogyan használható?

• xml1.ppt, soap.ppt

XSL - szerepe, formai kialakítása. Mire jó az XSL? Milyen egy XSL belsõ szerkezete? A feldolgozás alapötlete. Fõ nyelvi elemek. XSLT.

• xml2.ppt

XML security. Hogyan lehet aláírni? Hogyan és mit lehet titkosítani? Miért kell kanonizálni?

• xml3.ppt

Adatbázis - JDBC és kialakítása. Hogyan tud kapcsolódni egy alkalmazásszerver az adatbázisokhoz? Hogyan kell servlet/MVC esetében használni a JDBC-t?

• adatbazis.ppt

Alkalmazásszerver - lényege, konténerek. Melyek az alkalmazásszerver feladatai? Konténerek bekapcsolása. J2EE tanúsítvány jelentõsége.

• alkszerver.ppt

TCP/IP - routing. Alapelvek, routing fajták, routing protokollok

• útválasztás
• IP-cím alapján állapítja meg, hogy melyik LAN-ba kell küldeni a csomagot
• de hogyan válassza meg az utat, ha több létezik?
• routing table oszlopai: N, IF, metric
• a router mint fizikai eszköz tartalmazhat gateway funkciót
• sebesség: packets per second
• routing table alapján, hogyan töltsük ki?
  • statikus routing: kézzel töltjük ki
  • dinamikus routing: egy algoritmus tartja karban
• protokollokat (EGP, IGP, BGP, RIP) átnézni

TCP/IP - a Domain Name System. Felépítés, mûködés. Magasszintû protokollok: ftp, telnet, smtp

• domain név -> IP leképezés: kezdetben /etc/hosts
• Jonathan Postel ötlete
• fordított fastruktúra
• elosztott adatbázis
• resolver algoritmus: fastruktúrán föl megfelelő szintig, majd le
• NS-ek UDP-t használnak
• NS-ek resource rekordjainak típusai:
  • Address (gépnév – IP-cím)
  • NameServer (zónanév – IP-cím)
  • MailXchange (kukac utáni zónanév – lekezelő gépnév)
  • CNAME (gépnév – gépnév alias)
  • TXT (megjegyzés)
  • LOCation (gép földrajzi koordinátája)

TCP/IP - Az IPv6 protokoll. Fejléc, címzés, IPv6-IPv4 különbségek

• network layer for packet-switched internetworks, the successor of Ipv4
• conservative extension: Most transport- and application-layer protocols need little or no change, but applications protocols need much larger address space: addresses in IPv6 are 128 bits long versus 32 bits in Ipv4; makes subnetting easier
• Stateless address autoconfiguration using ICMPv6 router discovery messages
• IPv6 addresses are typically composed of two logical parts: a 64-bit (sub-)network prefix, and a 64-bit host part
• IPv6 addresses are divided into 3 types:
  • Unicast Addresses
  • Multicast Addresses
  • Anycast Addresses
• The IPv6 packet is composed of two main parts: the header and the payload.
• The header is in the first 40 octets (320 bits) of the packet and contains:
  • Version - version 6 (4-bit IP version).
  • Traffic class - packet priority (8-bits). Priority values are divided into ranges: traffic where the source provides congestion control and non-congestion control traffic.
  • Flow label - QoS management (20 bits). Originally created for giving real-time applications special service, but currently unused.
  • Payload length - payload length in bytes (16 bits). When cleared to zero, the option is a "Jumbo payload" (hop-by-hop).
  • Next header - Specifies the next encapsulated protocol. The values are compatible with those specified for the IPv4 protocol field (8 bits).
  • Hop limit - replaces the time to live field of IPv4 (8 bits).
  • Source and destination addresses - 128 bits each.

Hálózat biztonság. A Kerberos rendszer mûködése. Alapfogalmak, üzenetek.

A kerberos hitelesítő protokoll segítségével egy nem biztonsgáos hálózat felett biztonságosan meggyőződhetnek a felek egymás identitásáról. Az MIT -n dolgozták ki. A Kerberos a Needham-Schroeder protokollt használja. Egy megbízható harmadik felet, un. KDC -t, Key Distribution Centert használ. A KDC logikailag két részre bomlik, AS (Authentication Server), illetve TGS (Ticket Granting Server). A Kerberos tikettekkel dolgozik. A KDC a kulcsokról egy adatbázist tart nyilván, minden a hálózaton résztvető elem, akár szerver, akár kliens birtokol egy titkos kulcsot, melyet rajta kívül csak a KDC ismer. Hogy két fél kommunikáljon, a KDC egy un. session kulcsot készít, melynek segítségével a felek kommunikálni tudnak biztonságosan. A Protokoll biztonsága nagyban függ a résztvevő felek szinkronizált óráitól, és a rövid idejű, hitelességet feltételező kerberos tikettektől. A komponensek:

• AS = Authentication Server
• TGS = Ticket Granting Server
• SS = Service Server
• TGT = Ticket Granting Ticket

A protokoll rövid leírása:

• A kliens hitelesíti magát az Authentication Server felé egy hosszúéletű közös titok segítségével.
• A kliens az AS -től egy tikettet kap
• Később a kliens a kapott tikettel újabb tiketteket kaphat az SS -hez, anélkül, hogy a közös titkot használná.
• A kért tikettek hitelesítik az SS számára a klienst.

A protokoll részletes leírása:

• Felhasználó belép a kliens gépre:
  • Béla beüti a jelszavát
  • BélaKliens egyirányú hesselést csinál a bepüfölt jelszavon, ez lesz a kliens titkos kulcsa.
• Kliens hitelesítési lépések:
  • A kliens egy cleartext szöveget küld az AS -nek, hogy a user nevében szolgáltatásokat kérjen. Ebben az üzenetben semmiféle titkos kulcs, ill jelszó nem kerül elküldésre. Egy ilyen minta üzenet: Béla szeretne majd szolgáltatásokat kérni. (Tehát itt még nem tudja, mit, valamit)
  • Az AS leellenőrzi, Béla benne van e az adatbázisában, ha igen, akkor visszanyomja a kliensnek a következő információkat:
    • _MESSAGE A_: BélaKliens/TGS session kulcs, a közös titokkal bekódolva.
    • _MESSAGE B_: Ticket Granting Ticket (benne van a kliens azonosító, kliens címe, tikett érvényességi periódusa, és a *BélaKliens/TGS session kulcs*), ez az üzenet a TGS kulcsával van bekódolva.
  • A kliens megkapja a fennti üzeneteket, a MESSAGE A -t dekódolja, hiszen az a közös titokkal van bekódolva, ebből kinyeri a BélaKliens/TGS session kulcs -ot. Ezen kulcs segítségével fog a továbbiakban a TGS -el kommunikálni. (Megjegyzés: A MESSAGE B -t nem tudja Béla gépe kikódolni, mert az a TGS kulcsával van bekódolva.
• Kliens Szolgáltatáshitelesítési lépései:
  • Amikor szolgáltatásra van szükség, a kliens a következő üzeneteket küldi el a TGS -nek:
    • _MESSAGE C_: ez az üzenet a MESSAGE B -ből, és a szolgáltatás ID -jából áll.
    • _MESSAGE D_: Hitelesítő infó (Kliens ID, és időbélyeg), bekódolva a BélaKliens/TGS session kulcs csal.
  • Na, ezt megkapja a TGS, a MESSAGE C -ből kiszedi a MESSAGE B -t, és a MESSAGE B -t kikódolja a saját kulcsával. A kikódolásból megkapja a BélaKliens/TGS session kulcs -ot. Na, ezzel már dekódolja a MESSAGE D -t, és elküldi a következőket:
    • _MESSAGE E_: BélaKliens-Nyomtatószerver tikett (Kliens ID, kliens hálózati cím, érvényesség, *BélaKliens-Nyomtatószerver kulcs*), mindez bekódolva a szerver (nyomtatószerver) titkos kulcsával.
    • _MESSAGE F_: BélaKliens-Nyomtatószerver tikett bekódolva a BélaKliens/TGS szerver kulccsal
• Kliens szolgáltatást kér:
  • Na, Béla gépének már megvan a MESSAGE E, és a MESSAGE F, ez már elég, hogy bebizonyítsa magát az SS felé, és nyomtasson végre. Hozzácsatlakozik a szerverhez, és elküldi a következőket:
    • az előző aktusból származó MESSAGE E
    • _MESSAGE G_: egy új Hitelesítő infó (Kliens ID, időbillog) bekódolva BélaKliens/Nyomtatószerver session kulcs al.
  • Az SS az első üzenetet dekódolja (_MESSAGE E_), ellenőrzi, jó e a timestamp. Ha minden rendben, akkor visszaküldi, hogy mennyire szeretne nyomtatni a Bélának:
    • _MESSAGE H_: A MESSAGE G -ben talált hitelesítő infó + 1, bekódolva a BélaKliens/Nyomtatószerver session kulcs al.
  • Na, Béla Kliense kicsomagolja az üzenetet, és ellenőrzi, vajon tényleg jól hozzáadott e 1 -et a nyomtatószerver az időbélyeghez. Ha igen, akkor lehet nyomtatni.
  • Béla nyomtat

• Kerberos builds on symmetric key cryptography and requires a trusted third party.
• Needham-Schroeder protocol
• key distribution center (KDC): two logically separate parts: an Authentication Server (AS) and a Ticket Granting Server (TGS)
• protocol:
  • C: key = hash(password)
  • C->AS: authentication request
  • AS->C: TGS session key encrypted with key, ticket-granting ticket encrypted with key of TGS
  • C: decrypt(TGS session key)
  • C->TGS: TGT+service ID, client ID+timestamp encrypted with TGS session key
  • TGS->C: client-to-server ticket encrypted with service key, server session key encrypted with TGS session key
  • C->SS: client-to-server ticket encrypted with service key, client ID+timestamp encrypted with server session key
  • SS->C: timestamp+1 encrypted with server session key
  • C: decrypt and check timestamp+1

Web technológiák: web architektúra. A HTTP1.0 és HTTP1.1 protokollok.

• webtechnology.ppt

Web technológiák: a Secure Socket Layer (SSL) mûködése.

• Application layer
• prevent eavesdropping, tampering, and message forgery
• server-only or mutual authentication
• basic phases:
  • 1.Peer negotiation for algorithm support
  • 2.Key exchange and authentication
  • 3.Symmetric cipher encryption and message authentication
• typical algorithms:
  • For key exchange
  • For authentication
  • Symmetric ciphers
  • For cryptographic hash function
• handshake

Melyek a SOAP fõ jellemzõi? Mi a webservice, hol és hogyan lehet alkalmazni?

• soap.ppt

Mutassa be az "Inversion of Control" konténereket általában. Milyen tervezési mintákat használhatunk a komponensek létrehozásakor? Spring keretrendszer esetén hogyan írjuk le a komponenseket és hogyan hivatkozunk rájuk?

• spring_introduction.pdf
• IoC: the desired responses are registered to particular events ("don't call us, we will call you")

Vázolja a komponens alapú tervezés elõnyeit. Milyen problémák jelentkeznek a komponensek összekapcsolásakor. A Spring keretrendszer hogyan oldja meg ezeket? Milyen lehetõségek vannak a függõségek és paraméterek beállítására?

• decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components
• a higher level of abstraction than objects and as such they do not share state and communicate by exchanging messages
• Multiple-use
• Non-context-specific
• Composable with other components
• Encapsulated i.e., non-investigable through its interfaces
• A unit of independent deployment and versioning

Milyen problémákat old meg az object-relational mapping (ORM)? Milyen jellemzõkkel bírnak az adatbázisban tárolt entitások? Milyen objektumokat használhatunk JPA esetén és milyen módon írjuk le a tárolás módját? Mire jók az annotációk általában, hogyan definiálhatjuk azokat?

• object_relational_mappin.pdf
• Java Persistence API

Ismertesse az entitások tárolási módjának megadását JPA esetén. Hogyan adjuk meg az elsõdleges kulcsot és a mezõk jellemzõit? Milyen reláció típusok vannak és hogyan adjuk meg azokat, hogyan képzõdnek le ezek Java nyelvi elemekre?

• EJB3_advanced_concepts.pdf
• A persistence entity is a lightweight Java class that typically represents a table in a relational database.

Vázolja a többrétegû architektúrát és elemeit. Melyek a tranzakciók jellemzõi? Mit jelent deklaratív tranzakció kezelés?

• EJB3_advanced_concepts.pdf
• a frequent client-server architecture
• Presentation Tier
• Application Tier (Business Logic/Logic Tier)
• Data Tier

Vázolja az entitások életciklusát! Milyen metódusok állnak rendelkezésre az életciklus kezelésére? Hogyan lehet lekérdezéseket leírni JPA esetén?

• EJB3_advanced_concepts.pdf
• Relations between objects can be traversed using Java-like syntax
• the from clause of a query includes not only instances of the specific entity class to which it refers, but all subclasses of that class as well parameterized queries

Intelligens háttértár rendszerek. A SAN fogalma, mûködése, elõnyei.

Kis történeti áttekintés: Kezdetben volt a DAS (Direct attached storage). Ez gyakorlatilag egy szerver, telepakolva mindenféle winchesterrel, RAID vezérlővel. Az alkalmazások közvetlenül a winchestert címzik SCSI buszon, vagy SAS-on, vagy IDE-n. Hátránya, hogy amennyiben növekszik a cég háttértár igénye, újabb tárolókapacitást kell beletenni a szerverbe. Ennek korlátot szab a szerverben lévő helyek száma. Új tárhelyhez új szerver kell. Egy idő után jó sok szerver lesz, mindet külön karban kell tartani, megnőnek az üzemeltetési költségek. Ugyancsak hátrány, hogy a szerver más feladatokat is ellát, így a rendszer szűk keresztmettszetévé válik. Egy nagy sávszélesség igényű alkalmazás lelassítja a fájl elérést a szerveren keresztül. Ha egy alkalmazás karbantartása miatt újraindítás kell, a fájlszolgáltatás is megszűnik.

A NAS (Network Attached Storage) jön képbe ezután. A lényege, hogy van egy dedikált eszköz, vagy szerver, mely fájl szintű adathozzáférést biztosít. Lehet kapni dobozos eszközöket, vagy bárki építhet egy NAS -t egy Linux boxból, és egy NFS /CIFS szerverből. Itt a háttértárat ugyanúgy a rendszer hálózaton keresztül lehet elérni (IP). Gyakorlatilag annyi a különbség a DAS -hoz képest, hogy itt a szervert kizárólagosan fájlmegosztásra használjuk.

A SAN (Storage Area Network) egy dedikált, gyors hálózat, blokk szintű tármegosztással. A SAN infrastruktúrában a háttértárak legtöbbször Fibre Channel technológiával vannak összekötve. A Fibre Channel az SCSI minden előnyét élvezi, mindamellett, tekintve hogy nem egy párhuzamos busz, nagy távolságokban is használható. A SAN ereje a nagy blokkok mozgatásában rejlik. Hátránya a drágaság, a Fibre Channel eszközök nagyon költségesek, és elterjedését hátráltatta a szabvány lassú kifejlődése.

Intelligencia: A SAN eszközökkel kapcsolatos fogalom a Storage Virtualization. Ennek segítségével a logikai tárolás elválasztható a konkrét fizikai tárolástól. A fizikai eszközökből egy pool látszik, mely pool -on lehet definiálni logikai meghajtót. Egy cikket találtam Data Storage Interviews August 20, 03 The route to the intelligent SAN, melyben a SAN -ok intelligenciája alatt a következőket értették: A SAN routerekbe beépíthető, felprogramozható, adaptálódó funkciók. Gyakorlatilag egy nagyobb SAN hálózatban a felhasználás helyéhez közelebb mozgatja az adatot a SAN hálózat, ezáltal nagyobb sebességet elérve. A SAN intelligencia a hálózatba van beépítve. Programozható intelligens switchek, központi vezérlő motorral. A switchet pl. felprogramozzák, pl. hogy tükrözzön minden adatot egy másik eszközre. Ezzel a feature -el nem kell minden adatmozgatásnak keresztül mennie a szerveren.

SAN előnyök:

• Nagyon gyors, blokk szintű tárhely megosztás
• Nagy távolságok is áthidalhatóak vele
• Redundáns rendszer, 24x7 -es rendelkezésreállás
• Bővíthető rendszer

SAN hátrányok:

• Drága
• Gyártónként egyedi management felület

Régi cuccos:

• Storage Area Network
• an architecture to attach remote computer storage devices to servers in such a way that the devices appear as locally attached
• needs SAN file systems
• topology: switched fabric
• simplifies storage administration
• the ability to allow servers to boot from the SAN itself
• more effective disaster recovery processes (storage replication)

A Fibre Channel (FC) technológia. Jellemzõk, topológiák, protokoll.

Kis történeti betekintés: Nő a számítógépek sebessége, és a hagyományos párhuzamos SCSI technológia hátrányai kidomborodnak. Nagy átvitel kell a nagy sebességű processzoroknak. A merevlemezek megfelelnek a kihívásoknak, de az interfészük már nem. A probléma megoldására az új driveok FC interfésszel rendelkeznek, mely 100 Megabájt per szek sebességű, és növelés tervezett. A technológia nyújtja a teljesítménybeli megoldást, és a jövőbeli igényeknek is jobban megfelel. Azáltal, hogy a SCSI parancsokat becsomagolják az FC fizikai interfészbe, a migráció könnyedebbé válik.

Az FC eszközök kapcsolatát két kábel adja, egyik a bemenő, a másik a kimenő adat.

A Fibre Channel technológia egy nagysebességű hálózati technológia. A SAN -ok kialakítására használatos. Fizikai rétege lehet kettős axiális kábel, vagy üvegszál. a Fibre Channel Protokoll FCP egy átviteli protokoll, mely nagyrészt SCSI parancsokat szállít a FC hálózaton.

• Topológiák:
  • Point-to-Point: két eszköz összekötve, a legyegyszerűbb topológia
  • Arbitrated loop: Az eszközök egy gyűrűt alkotnak. Áj eszköz hozzáadásakor, vagy kivételekor a teljes hálózat megbénul. Egy eszköz megsérülésekor szintén megbénul a hálózat. FC hubokkal összekötve az eszközöket a hibás portok kikerülhetőek.
  • Switched fabric (FC-SW): Fibre Channel switch -ekkel összekötött eszközök, vagy loop -ok, a switchek biztosítják az optimális összeköttetést.
• protocol stack:
  • FC0 The physical layer, which includes cables, fiber optics, connectors, pinouts etc.
  • FC1 The data link layer, which implements the 8b/10b encoding and decoding of signals.
  • FC2 The network layer, defined by the FC-PI-2 standard, consists of the core of Fibre Channel, and defines the main protocols.
  • FC3 The common services layer, a thin layer that could eventually implement functions like encryption or RAID.
  • FC4 The Protocol Mapping layer. Layer in which other protocols, such as SCSI, are encapsulated into an information unit for delivery to FC2.

Belsõ hálózatok védelme: fizikai, algoritmikus, adminisztratív védelem, biztonsági politika.

• Threats: email, IM, physical, FTP, VPN, new hires

Tûzfalak alapvetõ típusai, csomagszûrõ és proxy tûzfal.

• a device or set of devices configured to permit, deny, encrypt, or proxy all computer traffic between different security domains
• packet filter: at network layer
• stateful p. f.: against exploiting existing conneciton, DoS attacks
• application layer
• A proxy device may act as a firewall by responding to input packets in the manner of an application, whilst blocking other packets.
• NAT (network address translation)

POSIX célkitûzése. POSIX.1 alapjául szolgáló rendszerek. Szabvány által megfogalmazott követelmények szintjei. A szabványosság szintjei.

POSIX célkitűzése:

80 -as évek végére thető. Cél: létrehozni egy egységes operációs rendszer programozási felületet. Azért szükséges, mert így az alkalmazások hordozhatóak lesznek. Ekkor már kiforrottak voltak a különféle UNIX rendszerek. POSIX (Portable Operating System Interface).

POSIX.1 alapjául szolgáló rendszerek:

A POSIX.1 a rendszerinterfész C nyelven. Alapjául szolgálnak:

• System V
• BSD

A POSIX.1 nem szabja meg, mely függvények legyenek rendszerhívások, és melyek nem.

A szabvány által megfogalmazott követelmények szintjei:

A szabvány követelményeket támaszt egyrészt az Operációs rendszerrel szemben, másrészt az alkalmazásokkal szemben. A támasztott követelményeket a következőképpen lehet osztályozni:

• _Implementáció által definiált_: A szabvány nem köti meg, miként működjön, vagy mennyi legyen az értéke, de megköveteli, hogy le kell dokumentálni a pontos értéket. Pl.: filenév minimum 15 karakter legyen, ezt köti meg a szabvány. Hogy a konkrét operációs rendszeren van e felső limitje a fájlnév hossznak, és mennyi az, azt le kell dokumentálni.
• _Nem specifikált_: Az adott működést, vagy értéket nem specifikálja a szabvány. Pl.: Ha egyszerre érkeznek a signal -ok, akkor mi legyen a viselkedés.
• _Nem definiált_: Olyan működés, vagy funkció, mellyel szemben hibátlan program nem támaszthat követelményt.
• _Kell_: Pontosan előírja a szabvány, miként kell működjön az adott funkció, mennyi legyen a változó értéke.
• _Kellene_: Javaslatot ír elő, hogyan működjön, vagy mennyi legyen az értéke, de az implementáció eltérhet ettől.
• _Lehet_: Egy opciót jelöl, amit nem kötelező megvalósítani.

A szabványosság szintjei:

Ez szabja meg, egy alkalmazás mennyire szabványos. Itt négy szintet határoz meg:

• _Szigorúan megfelelő_: Olyan alkalmazás, amely csak POSIX szabványra épül, és hibátlanul működik a Nem specifikált, és Implementáció által definiált követelmények összes értékével.
• _ISO/IEC megfelelő_: A POSIX mellett felhasznál még nemzetközi szabványokat is. (ISO/IEC)
• _Nemzeti szabványokat is felhasználó_: Az alkalmazás nemzeti szabványokat is felhasznál
• _Egyéb, nem szabványos kiterjesztéseket használó alkalmazás_: Olyan POSIX alkalmazás, mely felhasznál nem szabványos kiterjesztéseket is.

POSIX.1 fontosabb témakörei, megvalósítás filozófiája. Rendszerfüggés problémái, a megoldás módszerei.

A POSIX.1 fontosabb témakörei:

• Processz kezelés
• Állománykezelés
• Szignálkezelés
• Terminálkezelés

Processz kezelés

A POSIX környezetben a processzek konkurensen futnak, processzt létrehozni a fork() rendszerhívással lehet. A processzkezelésnél alapvetően a System V rendszerekben alkalmazott megoldások köszönnek vissza. A BSD rendszerekből átvett fogalmak: kiegészítő csoportazonosítók, szignál maszk.

Kiegészítő csoportazonosítók

Minden processz tagja egy szekciónak, és egy processzcsoportnak is. Egy szekcióhoz több processzcsoport is tartozhat. Ez a BSD job koncepciónak felel meg.

Szignál maszk

lásd később, a szignáloknál.

A processzek legfőbb tulajdonságai:

• PID - Process Identifier, egyedi azonosítószám
• PPID - Parent PID, a szülő processz azonosítója
• PGID - Process Group ID, a processz csoportazonosító
• Login név
• UID - valós felhasználói azonosító
• Effektív UID - ez a setuid bittel rendelkező processzeknél eltérhet a valós UID -tól
• GID - valós felhasználói azonosító
• Effektív GID - ez is a set-uid bites alkalmazásoknál játszik.
• Kiegészítő csoportazonosítók
• Munkakatalógus
• UMASK - állományok létrehozási maszkja, egy bitmaszk, mely minden, a processz által létrehozott állomány védelmi attribútumainak kialakításában részt vesz.
• Szignál maszk
• Terminál azonosító
• szekció azonosító
• Futási idők.

A processzkezeléshez használatos függvények: abort(),exit(),execl(),execle(),execlp(),execv(),execve(),execvp(),wait(),waitpid()

Állománykezelés

• Az állományok neveit egy nem tisztán fa struktúrájú hierarchiában képzeljük el.
• Öt féle állománytipust különböztet meg a szabvány:
  • normál állomány (regular file),
  • katalógus (directory),
  • FIFO
  • blokkos elérésű eszköz,
  • karakteres elérésű eszköz.
• Javasolja, hogy az állományok nevei hordozható állománynevek legyenek, azaz:
  • angol abc kis és nagy betűi
  • egyéb karakterek: . _ - (pont,aláhúzás,kötőjel)
• Az állománynevek a */* karakterrel legyenek elválasztva, egymás után több ilyen jel azt jelenti, hogy csak egy van. Útnév elején nem lehet több /.
• Az állományok legfontosabb tulajdonságai:
  • Állomány tipusa
  • Hozzáférés védelmi kódja: Védelmi kód terén legalább a UNIX 3x3 as védelme, ha annál jobb, akkor:
    • állományonként be/kikapcsolható legyen
    • az alkalmazói szempontból ugyanúgy kell megjelennie, mint az eredeti 3x3 as, tehát létezzék a tulaj, csoport, bárki fogalmak mindegyike.
    • Ha engedélyezve van, akkor a korábbi védelmet felülírva jelenik meg a rendszerhívásoknál (*stat,fstat*)
  • Egyedi azonosítószám (i-node)
  • hivatkozás számláló
  • tulajdonos UID, GID
  • állomány hossza bájtban
  • utolsó módosítási idő
  • utolsó hozzáférési idő
  • utolsó státusz módosítási idő, amikor a struktúra módosítva lett, gyakorlatban az i-node módosítási ideje
• Nem használható az mknod() hívás, helyette, a speciális fájlokhoz: mkdir(), mkfifo()
• Katalógusok kezelésére külön interfész: mkdir(), rmdir(), opendir(), readdir(), rwinddir(), closedir()
• katalógusoknál átnevezéshez nem használható a link() unlink(), hanem bevezeti a rename() rendszerhívást.
• Az állományok megnyitásánál nem lehet használni az O_SYNC flag -et, ls a sync() rendszerhívást, helyette fsync() rendszerhívás
• dup() egy megynitott fájl leírót lehet lemásolni, a másolaton keresztül is ezt érem el
• dup2() ezzel meg lehet mondani, hogy a megnyitott fájlok struktúrájában hol keressen szabad helyet.
• el lehet seek() eltetni a fájlt, lehet benne luk. definíció szerint a lukból olvasva 0 -át kapunk.

Szignálkezelés

Ezen a téren a POSIX szakított mind a BSD, mind a System V filozófiával. A probléma, ami miatt ez következett be a következő: Mi van, ha egy szignál érvényre jut, majd elindul a kezelő rutin, és közben bejön újra ugyanaz a szignál?

• System V: a szignál érvényrejutásakor visszaáll alapértékre. Ha ez az alkalmazásnak nem felel meg, akkor a kezelőrutinban újra át kell venni, különben az alapértelmezett tevékenységet hajtja végre a rendszer, ami a legtöbb esetben programmegállás. Amennyiben a program nem tudja elég hamar visszavenni a szignált, ki fog lépni, és ez előfordulhat.
• BSD: nem áll vissza alaphelyzetbe. Feltételezi, hogy a kezelő rutin újrabelépő, ez nem mindig megvalósítható.
• *POSIX*: Hardveres szemlélet, minden szignálkezelő rutin mellé adunk egy maszkot is. Ez a maszk mondja meg, mely szignálok nem juthatnak érvényre.

hívások tehát: sigaction() A processz szignál maszkja a sigprocmask() függvénnyel állítható, szignálkezelő rutin esetén az érvényes maszk a processz szignál maszkja, unio a szignálkezelő maszk, unió az aktuális szignál.

Terminálkezelés

• speciális vezérlőkarakterek maradtak, megmaradt a kanonikus, és a nem kanonikus mód. megszűnt az ioctl(), tál sokoldalú volt, helyette:
• tcsetattr(),tcgetattr()
• Fontos a struktúrált, átlátható terminálkezelés, és minden programnak biztosítania kell, hogy visszaállítja az elállított terminál paramétereket.

OLD STUFF:

• posix.ps
• Process Creation and Control
• Signals
• Floating Point Exceptions
• Segmentation Violations
• Illegal Instructions
• Bus Errors
• Timers
• File and Directory Operations
• Pipes
• C Library (Standard C)
• I/O Port Interface and Control

POSIX.1 alapjául szolgáló rendszerek. Fôbb tématerületek a POSIX.1-ben. File rendszer filozófiája. Fontosabb rendszerhívások file, és terminálkezelés területén.

• posix.ps
• UNIX

Hordozható adatformátumok. Felmerülô problémák, elvi megoldások.

A POSIX meghatároz egy egységes operációs rendszer API -t, így a programozó szemszögéből minden rendszer hasonlít. Meg kell még oldani, hogy az egyes architektúrán érvényes korlátozások is beépüljenek a programba, hordozható legyen a forráskód, esetleg maga a bináris állomány is, valamint a konfigurációs fájlok. Az install scriptekről nem is beszélve. Hogy az alkalmazás rugalmasan tudjon alkalmazkodni a konkrét architektúrához, két lehetőség kínálkozik:

• Fordítási időben: feltételese fordítási opciók és konstansok használatával. Ezt a C nyelv az unistd.h állomány konstansaival biztosítja.
• Futási időben: sysconf(),pathconf(),fpathconf() függvények

A POSIX maszatol a többi részlettel kapcsolatosan, miként lehet átvinni az adatokat, programokat. A hordozható adatformátumokról a POSIX.2 nyilatkozik a hordozandó alkalmazásról:

• Kell az alkalmazás forráskódja:
  • A kódkészlet problémája merül fel. A POSIX az ISO 646 kódkészletre épül. Ezen kódkészletben sajnálatosan nincsenek benne olyan karakterek, amik viszont fellelhetőek a C forráskódban. Ennek kiküszöbölésére a javaslat, hogy un. trigraph karakterekkel "eszképeljék" ki ezen karaktereket. Ezek gyakorlatilag 3 karakteres betűsorozatok.
• A bináris hordozása:
  • A POSIX.1 utal arra, hogy létezik egy ABI, Application Binary Interface, amivel megoldható a probléma kezelése. A másik megoldás az ANDF (Architecture Neutral Distribution Format), amely egy közbülső kódot definiál, amelynek alapján a végleges kód legenerálható
• Az alkalmazás adatai, és a dokumentáció
  • Itt a számábrázolások a fontosak, mert ha mondjuk 32 bites rendszeren kiírok egy integert, majd beolvasom egy 64 bitesen, nem fog stimmelni. A problémát áthidalhatjuk szöveges átvitellel.
• install scriptek:
  • POSIX.2 ezt részletesen taglalja

Figyelmet kell szentelni annak, hogy az állománynevek ne tartalmazzanak abszolút hivatkozást. A csomag előállításához régen a tar, ill cpio álltak rendelkezésre. A tar nem viszi át a device állományokat, a cpio meg a linkeket nem visz át. A mostani gnu tar mindent tud.

• XML?
• karakterkódolás?
• Little/Big Endian?

Elosztott párhuzamos rendszerek, alapelvek, eszközök. Grid koncepció.

• rinteg_eloszt.pdf

-- thSoft - 2008.06.07.