Eddigi ZH-kérdések

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen KornAndras (vitalap | szerkesztései) 2006. november 20., 16:07-kor történt szerkesztése után volt.

Az alábbiakban leírom az eddig szerepelt zh-kérdéseket, a hozzájuk tartozó helyes válaszokat (ezeket a zh-ban elvárt minimális részletességnél szabatosabban kifejtve), és esetleg néhány, a hallgatók által írt választ, kommentárokkal. Az olvashatatlan szavakat "????" jelöli; a megtippelt, de nem jól olvasható szavakat "????megtippelt_szó????". A helyes válaszokban zárójelben szereplő mondatok csak kiegészítik a választ, nem elvárás, hogy a zh-ban is leírjátok őket.

A megadott pontszámok a zh-ban szereplő pontszámok; elvileg a kérdések relatív nehézségén és fontosságán kívül azt is hivatottak tükrözni, mennyire részletes választ várok el. A későbbiekben a tapasztalatok alapján ezek a pontszámok módosulhatnak, és egy itt leírt négypontos kérdés legközelebb szerepelhet pl. hatpontosként.

Sajnos a zh-k helyesírása és magyarsága több esetben hagyott kívánnivalót maga után. Szerintem helytelenül írni igénytelenség. Ezzel persze nem kötelező egyetérteni, és a pontozásnál sem vettem figyelembe a nem értelemzavaró hibákat, de azért próbáljatok erre is odafigyelni.

Tartalomjegyzék

1 Unix-alapok

  • Mit jelent a kiegészítő csoporttagság (supplementary group membership)? (4 pont)
Helyes válasz:
Egy unixos felhasználónak van egy felhasználó-azonosítója (UID) és egy csoport-azonosítója (GID), vagyis egy csoportnak mindenképpen tagja. Ez az elsődleges csoporttagság. Emellett a felhasználó más csoportoknak is tagja lehet; a /etc/group fájlban (vagy az ezt helyettesítő címtárban/adatbázisban) fel van sorolva, hogy az egyes csoportoknak mely felhasználók a tagjaik. Amikor a felhasználó belép, az őt beléptető processz a login shell elindítása előtt belép ezekbe a csoportokba is, és ezeket a csoporttagságokat a shell örökli tőle. Így tehát igazából a kiegészítő csoporttagságok halmaza a unixos processz egyik állapotváltozója.
Ha egy processz tagja egy csoportnak, akkor vonatkoznak rá a fájlrendszerben a csoportra vonatkozó jogosultságbitek.
Egy válasz a zh-ból (betű szerint):
az amikor egy felhasználó a /etc/group fileban nem csak a saját group-jában szerepel, hanem egyibb csoportokban is pl: audio,floppy. Így több fájlhoz is hozzáférhet a filok nála groupra vonatkozó rwx csoportnál ezeket a csoport tagságokat is figyelembe veszi. csak a változtatás után indított process-ekre igaz, hiszen igazából nem a felh.nak, hanem a process-eknek van UID-jük és GID-jük.
Kommentár: A válasz 2,5 pontot ér; több súlyos tévedést is tartalmaz, de ezekre szerencsére részben nem vonatkozott a kérdés.
A /etc/group file-ban az egyes csoportok tagjai vannak felsorolva, nem az, hogy az egyes felhasználók mely csoportoknak tagjai (ha így lenne, az utolsó csoporttag törlésével elvesztenénk a csoportot is). A /etc/group amúgy csak a kiegészítő csoporttagságokat tartalmazza, a felhasználó a GID-jához tartozó csoportnál alapértelmezés szerint nincs felsorolva.
Ha egy felhasználót berakunk egy új csoportba, akkor az általa indított új processzek nem kapják meg automatikusan az új csoporttagságot, hiszen a csoporttagságokat a szülőfolyamatuktól öröklik, az pedig nem rendelkezett ezzel a csoporttagsággal. Az új csoporttagságra új login session indításával vagy a newgrp segítségével lehet ténylegesen szert tenni.

2 IP-alapok

  • Mire való az ARP? Milyen üzenetei vannak? (5 pont)
Helyes válasz:
Az ARP arra való, hogy az egy fizikai hálózaton levő IP-vel kommunikálni vágyó számítógépek fel tudják deríteni egymás fizikai rétegbeli címét. Etherneten és az Ethernetre elegendően hasonlító hálózatokban használják.
Két üzenete van: a kérdés ("who-has 1.2.3.4 tell 1.2.3.1") és a válasz ("1.2.3.4 is-at 00:f0:0d:d0:0d:00").
(Az ARP nem IP-csomag, így nincs IP-fejléce.)
Adatkapcsolati szinten a kérdés forráscíme annak az állomásnak a címe, amely a választ tudni szeretné; a célcím a broadcast.
A válasz forráscíme annak az állomásnak a címe, amely tudja a választ (ez nem feltétlenül a keresett állomás); a célcím a kérdező állomás címe.
(Az ARP-kérdést elvileg nem muszáj broadcastként feltenni, de ez a leggyakoribb.)
(Az ARP elvileg többféle Ethernet felett szállítható protokollt is támogat.)
(Az ARP-kérdés a payloadban is tartalmazza a kérdező hardvercímét, és igazából erre a címre kell küldeni a választ.)
(Elvileg a RARP-üzenetek is az ARP-hez tartoznak, de nemigen használ ilyet senki.)
(A "who-has" és az "is-at" nevek a tcpdumphoz fűződnek, a szabvány kevésbé szemléletes neveken emlegeti az üzeneteket.)
Egy válasz a zh-ból (betű szerint):
ARP
IP->MAC megfeleltetés
who-has src mac: saját valós mac
dst mac: FF:FF:FF:FF:FF:FF
src IP: saját IP
dst IP: a cél IP-je
is-at src mac: cél saját mac-je
dst mac: saját mac
src IP: cél IP-je
dst IP: saját IP
Kommentár: a válasz 2,5 pontot ér. Súlyos hiba, hogy az ARP-t IP fölötti protokollként képzeli el. Nem írja le továbbá a who-has és az is-at üzenetek tartalmát.

3 DNS

  • Mekkora legyen egy rekord TTL-je? Miért éppen annyi? Miért baj, ha túl nagy, és miért baj, ha túl kicsi? (6 pont)
Helyes válasz:
Egy rekord TTL-je akkora legyen, hogy lehetőleg éppen a következő tervezett módosítás előtt járjon le. Ha nem tudjuk, mikor lesz a következő módosítás, akkor akkora legyen, amennyi ideig vállalható, hogy kliensek esetleg még a rekord régi tartalma szerint járnak el; tehát pl. az előző címén keresik a webszervert.
Ökölszabály: várhatóan lassan változó rekordok TTL-je legyen néhány órás (vagy akár néhány napos). Nem valószínű, hogy gyakran változna pl. egy domain MX-ének a neve, tehát az MX rekord TTL-je akár egy hét is lehet; a névhez tartozó IP viszont talán megváltozhat "váratlanul" (pl. mert átmegyünk másik hosting-szolgáltatóhoz, vagy mert DNS alapú failovert valósítottunk meg), így ennek a TTL-je lehet jóval alacsonyabb (néhány óra, vagy failover esetén akár csak öt perc).
Ha a TTL túl nagy, az azért baj, mert akkor a rekord tartalmának megváltoztatása után sokáig lehetnek olyan kliensek, akik a rekordnak még az előző tartalmát ismerik, és rossz gépnek próbálják kézbesíteni a leveleinket, rossz DNS-szervertől érdeklődnek a hosztneveinkről s.í.t. Ha az ebből adódó problémákat el akarjuk kerülni, akkor a rekord megváltoztatása után még legalább a TTL-ben megadott ideig mindkét címen (az újon és a régin) nyújtanunk kell a szolgáltatást.
Ha a TTL túl kicsi, az azért baj, mert a kliensek csak rövid ideig cache-elik a rekordok tartalmát és feleslegesen gyakran fordulnak a DNS-szerverünkhöz; így a szervernek megnő a terhelése, a kliensek pedig lelassulhatnak (mert pl. két kattintás között megint le kell kérdezni a webszerver IP-címét).
(Van olyan DNS-szerver, pl. a djbdns, amely tervezett DNS-változtatásokat úgy támogat, hogy a megváltoztatandó rekord TTL-jét minden válaszhoz egyenként kiszámítja úgy, hogy éppen a tervezett változtatás pillanatában járjon le.)
Egy válasz a zh-ból (betű szerint):
Általában néhány óra legyen egy DNS rekord TTL-je, ez szabja meg, hogy a kliens ezt meddit cachelheti. Ha túl nagy a TTL azzal az a baj, hogy lehet, hogy a rekord valami miatt megváltozott és erről csak nagyon későn a TTL lejárta után értesül a kliens. Ezért szolgáltatás kiesést okozhat.
Ha túl kicsi azzal az a baj, hogy folyton lekérdezi a kliens ezzel megterheli a DNS szervereket. Ezért optimális a pár óra. Ha nagyobb karbantartást szeretnénk végezni, akkor ????érdemes???? a TTL-t ????1-re 1s-ra???? ????állítani????, megvárni míg a régi ????lejár???? majd ????utána???? elvégezni a karbantartást, ezzel gyakorlatilag 0 lesz a szolgáltatás kiesés.
Kommentár: A válasz 4 pontot ér.
Alapvetően jó, de nem írja le, hogy a néhány óra egy olyan ökölszabály, amitől bizonyos esetekben érdemes eltérni (l. a DNS-alapú failover, ill. a szinte biztosan hosszú életű rekordok esetét).
Csak az ökölszabályt írja le, nem próbálja mérnöki módon megfogalmazni, mi alapján döntsük el, mennyi legyen a TTL.
Nem említi, hogy a szolgáltatáskiesés elkerülhető, ha a régi címen is fenntartjuk a szolgáltatást a TTL lejártáig (ami persze költséges és/vagy lehetetlen lehet).
Nem említi, hogy kliensoldalon is eredményezhet lassulást a túl kicsi TTL.

  • Mi a baj a glueless delegációkkal? Ugyanakkor mi a jó bennük? (10 pont)
Helyes válasz:
Egy delegáció kétféleképpen lehet glueless. Az egyik eset az, amikor olyan szervernek delegálunk egy domaint, amelynek a nevére nem vagyunk autoritatívak (pl. mondjuk a .hu-ra autoritatív szerver az ns.foo.com-nak delegálja a foo.hu domaint). Ebben az esetben a delegáló szerver nem adhatja át glue-ként a delegációban szereplő szerver A rekordját a kliensnek, mivel nincs joga nyilatkozni arról a domainről, amelybe az a szerver tartozik; a .hu nameserver nem autoritatív a .com-ra (elvileg lehetne autoritatív arra is, de ez most mindegy).
A másik eset az, amikor a delegáló szerver adatbázisába szándékosan nem vesszük fel az alárendelt szerver A rekordját annak ellenére, hogy megtehetnénk (mert autoritatívak vagyunk a nevére). Ez elég nagy marhaságnak tűnik; remélem, a valóságban senki nem csinál ilyet.
A baj a glueless delegációval az, hogy a kliensnek újra kell kezdenie a feloldást, esetleg a gyökértől, hogy megtudja a megkérdezendő szerver IP-címét; ha közben újabb glueless delegációval találkozik, akkor megint, s.í.t. Így nem biztos, hogy adható felső korlát egy feloldás memóriaigényére. Ráadásul a glueless-ség körbeérhet, és ebben az esetben a körben szereplő egyetlen domain sem oldható fel.
Pl. ha az a.com nameservere az ns.b.net, a b.net-é az ns.c.hu, a c.hu-é az ns.d.org, a d.org-é pedig az ns.a.com, akkor egyik domain sem elérhető, ha a delegációk glueless-ek, de mire ez kiderül, a rekurzív rezolver elpazarolt egy csomó időt és memóriát.
A glueless delegáció egyetlen "előnye" az, hogy a delegációval kapcsolatos NS rekordot tartalmazó zónába nem kell felvenni a delegációt kapó DNS-szerver A rekordját, így ezt a rekordot karbantartani sem kell, ha megváltozna (ehhez persze viszonylag bonyolult üzleti folyamatok tartozhatnak, úgyhogy nem feltétlenül egyszerű). Ez roppant kényelmes a delegációt végző szerver üzemeltetője számára, csak mindenki mással kitolás.
Hogy a mi domainjeinkre mutató delegációk gluelessek-e, azt mi magunk is befolyásolhatjuk; ha ügyelünk arra, hogy a domainre autoritatív szerver neve a domainen belül legyen (tehát a foo.com nameserverének neve a foo.com domainbe tartozzon, mondjuk ns.foo.com vagy a.ns.foo.com), akkor adunk esélyt a glue-nak.
Egy válasz a zh-ból (betű szerint):
A DNS-szerver a kérdezőnek delegáláskor a glue-ban átadhatja egy a keresett domainnel azonos zónába eső nameserver IP címét. Ez jó, mert így nem kell külön feloldani a nameserver ????nevét????, növekszik a DNS hatékonysága. Pl. a pool-foobar.axelero.hu megkérdezi a .hu zónáért felelős nameservert, hogy mi a www.bme.hu IP címe. A szerver válaszol, hogy ő nem authoritatív, de kérdezze meg az ns.bme.hu-t. Ilyenkor a kliensnek fel kellene oldani az ns.bme.hu-t is, ezt azonban a nameserver átadhatja glue-ban. Ha pl. a www.bme.edu-t próbáljuk meg feloldani, és a .hu-ért felelős name servertől kapjuk meg az ns.bme.edu IP címét, azt nem hisszük el neki.
A glueless delegációk rontják a DNS hatékonyságát, jó bennük, hogy pl. minden további nélkül megváltoztathatjuk a name serverünk IP címért, mert mindig feloldásra kerül a neve. Ez az előny elenyésző, érdemes használni a glue-t.
Kommentár: a válasz 9 pontot ér. Hibák:
A .hu zónáért felelős szerver természetesen autoritatív minden, a .hu alatti névre, így a www.bme.hu-ra is. Nem azt válaszolja az erre vonatkozó kérdésre, hogy nem autoritatív (ilyen válasz a DNS-ben gyakorlatilag nem is lehetséges), hanem egy delegációt tartalmazó választ küld.
Ha a .hu zónáért felelős szerver egy másik, .hu alatti szervernek delegál egy zónát, akkor annak a címét illik is átadnia glue-ban, hiszen kitől kérdezhetnénk meg, ha a .hu szerverek nem mondják meg?
A válasz első fele részben redundáns volt; nem volt kérdés, mi a glue (de persze inkább írjatok többet, mint kevesebbet). Ugyanakkor ez a bevezető győzött meg arról, hogy a hallgató valószínűleg érti, miért rontja a glueless delegáció a DNS hatékonyságát, mert azt külön nem írta le.

  • Mit jelent a DNS-ben a delegáció? Mondjon példát! (6 pont)
Helyes válasz:
Delegációnak - a kliens szemszögéből - azt nevezzük, amikor egy DNS-szerver válaszában nincs Answer section, csak olyan Authority section, amiben a kérdésben szereplő domainre, vagy egy a hierarchiában fölötte álló domainre vonatkozó NS rekordok vannak. Ebből a kliens megtudja, hogy melyik másik DNS-szervernek kell feltennie a kérdést a végső válasz reményében.
A DNS-adminisztrátor szemszögéből a delegáció az, amikor szubdomaint definiál, és ennek a karbantartását rábízza valaki másra: a szubdomainhez tartozó NS-rekordban megadott szerver üzemeltetőjére.
A DNS egésze szempontjából a delegáció az, ami hierarchikussá teszi a DNS-t, mint adatbázist. Elvileg a root szerverek minden névre autoritatívak, a valóságban azonban - a delegációnak köszönhetően - nem kell minden név összes rekordját ismerniük, hanem elegendő azt tudniuk, hogy a TLD-kre (top-level domainekre) mely szerverek autoritatívak; vagyis a TLD-ket delegálják azoknak a szervereknek, amelyek az egyes TLD-kre autoritatívak, s.í.t.
Példa: Ha valamelyik, a hu. zónára autoritatív szervertől megkérdezzük, mi a www.bme.hu domain A rekordja (ne feledjük, a DNS-ben minden domain, a "hosztnevek" is), a válaszban nem lesz Answer section (vagyis a keresett A rekord), de lesz olyan Authority section, amiben fel vannak sorolva a bme.hu domainre autoritatív szerverek (és lehet egy Additional section, amelyben ezek közül azoknak, amik szintén .hu alattiak - vagyis, véletlenül, az összesnek - benne lesz az A és/vagy AAAA rekordja is - ez a glue).
Példa az adminisztrátor szemszögéből: ha a hu. zónafájlba azt írjuk, hogy "bme.hu. IN NS ns.bme.hu.", akkor az ns.bme.hu-nak delegáltuk a bme.hu domainnel kapcsolatos kérdéseket.
Egy válasz a zh-ból (betű szerint):
Delegáció: ha csak azt mondjuk meg egy DNS-kérésre, hogy merre kell tovább tapogatózni a cím után.
Pl. ha a www.bme.hu keresésekor a *.hu-ra autoritatív DNS szerver címét kapjuk válaszként
Kommentár: a válasz 5 pontot ér. A delegációt, mint láttuk, többféle szemszögből meg lehet közelíteni; a hallgató a kliens oldaláról közelítette meg, és a lényeges információk többségét leírta. Hiányzik azonban, hogy kitől (ti. a root szervertől) fogjuk megkapni a .hu-ra autoritatív szerverek nevét (a címüket csak glue-ként). Ezek a pontatlanságok önmagukban nem súlyosak, de összesen indokolják egy pont levonását.

  • Mit jelent a DNS-ben az NXDOMAIN? (5 pont)
Helyes válasz:
Ha egy kérdésre azt a választ kapjuk, hogy NXDOMAIN, az azt jelenti, hogy sem a keresett domainnek, sem egyetlen aldomainjének sem a keresett típusú, sem más típusú rekordja nincs. Csak olyan szerver jogosult NXDOMAINnel válaszolni, amely autoritatív a keresett domainre; ha egy szerver csak autoritatív kérdésekre válaszol, és olyan domainről kérdezik, amire nem autoritatív, akkor nem válaszolhat NXDOMAINt, hanem csöndben kell maradnia (mert a DNS-ben nincs olyan válasz, hogy "nem vagyok autoritatív").
Egy válasz a zh-ból (betű szerint):
A DNS szerver biztosan állítja, hogy sem a kérdezett domén, sem annak aldoméne nem létezik. Ez nem egyenértékű azzal, hogy a DNS szerver nem ismeri a domént vagy nem autoritatív rá.
Kommentár: a válasz 4 pontot ér, mert nem fejti ki, mit jelent az, hogy egy domain "nem létezik" (ti. azt, hogy semmilyen típusú rekordja nincs), pedig igazából éppen ez volt a kérdés; az, hogy az NXDOMAIN a "domain" és a "(does) not exist" szavak valamilyen permutációjának rövidítése, elég evidens.

4 Az SMTP működése

  • Milyen módokon (nem mi alapján!) utasíthat el egy SMTP-szerver egy nem kívánt levelet? Melyiknek mi a következménye a levél későbbi sorsát illetően? (6 pont)
Helyes válasz:
- A TCP-kapcsolat elutasításával. A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.
- A TCP-kapcsolat bontásával az SMTP-kapcsolat során, a levél átvétele előtt. A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.
- Kliensoldali időtúllépés szándékos kiprovokálásával az SMTP-kapcsolat során (egyszerűen sokáig nem válaszol). A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.
- Az SMTP-tranzakció során, "ideiglenes" (négyessel kezdődő) válaszkóddal. A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.
- Az SMTP-tranzakció során, "végleges" (ötössel kezdődő) válaszkóddal. A kliens a levelet kézbesíthetetlennek tekinti és hibaüznetet küld a feladónak.
- (Minden ettől eltérő viselkedés - pl. ha átveszi a levelet, de nem kézbesíti, csak hibaüzenetet küld a feladónak, vagy még azt sem - a levél elfogadásának minősül az SMTP kontextusában.)
Egy válasz a zh-ból (betű szerint):
- nem épít fel a másik szerverrel TCP kapcsolatot
következmény: ha spammer vsz. nem próbálkozik újra ma már ez sajnos nem igaz.
ha nem spammer akkor újra próbálkozik kicsit lelassítja a valódi leevlek kézbesítését
- átmenetileg vissza utasítja
köv: 4xy hibakóddal átmenetileg visszautasitja a levél átvételét, késöbb lehet próbálkozni
- permanensen visszautasítja
köv: 5xy hibakóddal végérvényesen visszautasítja a levél átvételét, nem érdemes többszörprobálkozni
Kommentár: a válasz 6 pontot ér annak ellenére, hogy keveri a következményeket a módszerrekkel (jóra gondolt, de rosszat írt). Felsorolta a három legelterjedtebb módszert. Kicsit hiányzik, hogy mi történik, ha a későbbi próbálkozások is hasonlóan sikertelenek, de az SMTP-hibaüzenetek annyira közismertek, hogy bizonyára mindenki tudja, hogy ilyenkor hibaüzenet jön.

5 A HTTP működése

  • Milyen problémával kell számolnunk, ha HTTP virtualhostingot használunk, és SSL-re is szükségünk van? Milyen megoldásai vannak a problémának? (6 pont)
Helyes válasz:
A HTTP virtualhosting működési elve az, hogy a HTTP Host: fejlécében megmondjuk a webszervernek, melyik virtuális szerver címterében kell értelmezni a kérésben átadott elérési utat és fájlnevet. Ha HTTPS-t használunk, akkor a böngésző és a webszerver közötti TCP-kapcsolat felépülése után először az SSL handshake-re kerül sor; ennek során a böngésző hitelesíti a szervert, és többek között azt is ellenőrzi, hogy a szerver tanúsítványa az URL-ben szereplő hosztnévre szól-e.
A gond az, hogy a szerver ebben a pillanatban még nem tudja, hogy mi az URL, így, ha virtuális hosztokat használunk, nem tudja eldönteni, melyik virtuális hoszt tanúsítványával hitelesítse magát a böngésző felé; ha nem a jót választja, a böngésző hibaüzenetet ad (vagy az alkalmazásszintű proxy megtagadja a webszájthoz való hozzáférést). A szerver csak az SSL-handshake után, a HTTP-tranzakcióból tudja meg (a Host: fejlécből), hogy melyik virtualhostra kíváncsi a kliens.
Két megoldás van: az egyik az, hogy minden HTTPS-es virtualhostos külön IP:port páron futtatunk, így a szerver abból, hogy melyik IP:portra jött kapcsolatkérés, meg tudja állapítani, melyik virtualhostot szólítják meg éppen, és így azt is tudja, melyik tanúsítvánnyal kell hitelesítenie magát.
A másik megoldást csak akkor használhatjuk, ha minden virtualhostunk ugyanabba a domainbe tartozik, és a hitelesítő hatóságunk (CA, certificate authority) hajlandó nekünk joker-tanúsítványt adni erre a domainre; ekkor a tanúsítvány elvileg minden, az adott domainbe tartozó konkrét hosztnévre érvényes lesz, tehát a szerver nem kerül olyan dilemma elé, hogy több tanúsítvány közül kellene választania, vagyis az összes virtualhost maradhat ugyanazon az IP:port páron, hanem hitelesítheti magát azzal az eggyel, ami van. A módszer hátránya, hogy nem minden CA ad ki - és nem minden böngésző fogadja el - a joker-tanúsítványt.
Egy válasz a zh-ból (betű szerint):
Az a probléma, hogy a kliens elküldi a HTTP-kérésben a kért weboldal címét, ekkorra azonban már túl kéne esni az SSL-handshake-en, amihez kéne tudni a kért oldal címét (hogy melyikhez tartozó tanúsítványt használjuk). Megoldás:
1. különböző portra kell tenni a virtuális HTTPS-szervereket és port alapján tudjuk, melyik cert. kell
2. a domain-re vonatkozó cert. kell
Kommentár: A válasz 5 pontot ér. Fél pont levonás jár azért, mert nem fejti ki, mi "a domain" (impliciten feltételezi, hogy minden virtualhost ugyanabba a domainbe tartozik), és másik fél pont levonás azért, mert nemcsak külön portra, hanem külön IP-re is tehetjük az egyes virtuális szervereket; az IP:port párnak kell különböznie.

6 Filerendszerek

  • Fájlrendszerek kontextusában mi a fork? (3 pont)
Helyes válasz:
Ha a fájlrendszer lehetővé teszi, hogy egyetlen fájlhoz több, a fájlrendszer szintjén elkülönülő adatterület is tartozzon, akkor ezen adatterületek mindegyike egy-egy fork.
(A fájl érdemi tartalma a default fork; egyéb forkok tartalmazhatnak pl. bővített attribútumokat, POSIX ACL-eket, kép thumbnailjét, dokumentum meta-adatait stb.)
Egy válasz a zh-ból (betű szerint):
egy file-t több részletben több helyen tárolunk az FS-en ilyen lehet pl. mp3 ID3 tagjei, képek tumbnailjei, extended attribute-umok
Kommentár: A válasz 2,5 pontot ér, mert sajnos pontatlanul fogalmaz. Mit jelent az, hogy "több részletben, több helyen tároljuk"? A fragmentálódott fájlokat is több részletben, több helyen tároljuk, mégsem állnak szükségszerűen több forkból. A válasz igazából nem definiálta a forkot, csak mondott rá példát, amiből az ID3 tag ráadásul nem is jó példa, mert az szükségszerűen a fájl elsődleges adatterületének a része (persze az ID3 tagben található adatokat tarthatnánk egy - vagy egy-egy - forkban).

  • Mire jók a POSIX ACL-ek? Mondjon példát olyan jogosultságrendszerre, ami POSIX ACL-ekkel leírható, de hagyományos unixos jogosultságokkal nem! Bónuszkérdés: olyanra is tud példát, ami POSIX ACL-ekkel sem írható le? (10 pont)
Helyes válasz:
A POSIX ACL-ek egy olyan DAC (discretionary access control) mechanizmust valósítanak meg, amelynek segítségével csoportokra és felhasználókra lebontva megadhatjuk, hogy az adott inode-ra (fájlra, könyvtárra) kinek legyen olvasási, írási ill. végrehajtási joga. Az ún. "effective rights mask" segítségével valamennyi ACL-ből kimaszkolhatók bizonyos bitek (tehát pl. egyszerűen megvonható mindenkitől az írási jog akkor is, ha a saját ACL-je szerint van neki, és a mask újbóli módosításával visszaadható).
(Az ACL az Access Control List rövidítése.)
Mivel a POSIX ACL DAC-mechanizmus, nem pedig MAC (mandatory access control), a felhasználók a saját fájljaikon átállíthatják az ACL-eket, vagyis rendszerszinten sajnos nem kényszeríthetők ki vele bizonyos jogok bizonyos könyvtárakon.
Példa olyan esetre, ami unixos jogosultságokkal nem írható le: olyan fájl, amire az olvasó csoportnak olvasási joga van, az író csoportnak írási és olvasási joga is van, és azoknak a felhasználóknak, akik nem tagjai ezek közül egyik csoportnak sem, sem írási, sem olvasási joga nincs. (POSIX ACL-ekkel ezt egyébként így adhatjuk meg: setfacl -m g:olvaso:r--,g:iro:rw-,o:--- file)
Példa olyan esetre, ami POSIX ACL-ekkel sem írható le: egy végrehajtható fájl az egyik csoport számára legyen setuid root, a másik csoport számára egyszerűen végrehajtható, de ne setuidos. Ez azért nem oldható meg POSIX ACL-ekkel, mert a POSIX ACL-ek csak az rwx biteket tartalmazzák, a setuid, setgid, sticky biteket nem.
Egy válasz a zh-ból (betű szerint):
ACL Access Control List. Bonyolultabb hozzáférési jogrendszer mint a hagyományos unixos jogosultságok.
Pl. AFS-nél az hogy az AFS szerver gyökerén belül van egy Private mappa, Public és Public_html. Itt azt kell megoldani, hogy a public_html-t csak a webszerver olvassa viszont a publicot ne. Tehát ha egy szolgáltatásnak akarunk jogokat megadni azt ACL-el érdemes megtenni.
Kommentár: A válasz 2 pontot ér. A leírt példa lehet jó is, de a válaszból ez sajnos nem derül ki, mivel sajnos érthetetlen - mit jelent az, hogy "a publicot ne"? A publicot ne olvashassa a webszerver, vagy a publicot ne csak a webszerver olvashassa? És milyen jogok legyenek a Private könyvtáron? A POSIX ACL-ek szemantikájáról sajnos egy szó sem esik.

7 Software RAID Linux alatt

  • Mi a write-behind a linuxos softraid kontextusában, és mire jó? (5 pont)
Helyes válasz:
RAID1 esetén a tömb egyes elemein beállítható külön a write-mostly flag, és az egész tömbre a write-behind működés. A write-mostly hatása az, hogy az adott eszközről az md driver próbál nem olvasni, csak szinkronizálni rá; ez akkor jó, ha az adott eszköz lassú, mert így akkor csak az írást lassítja le, az olvasást nem. A write-behind-ot akkor tudjuk bekapcsolni, ha a tömbnek van write-intent bitmapje, és az a hatása, hogy a write-mostly-nak jelölt eszközökre aszinkron módon fog írni az md driver; ennek az az értelme, hogy ha pl. egy viszonylag lassú hálózati diszk is része a tömbnek, akkor annak a sebessége nem fogja vissza nagyon a teljes tömb írási teljesítőképességét, a tartalma mégis nagyjából szinkronban marad a tömb többi részével.

(Erre a kérdésre az a hallgató, akinek a zh-jában szerepelt, nem válaszolt.)


  • Mit jelent a linuxos softraid terminológiájában a RAID10? Mik a jellemzői? Mik a paraméterei? (8 pont)
Helyes válasz:
Itt elsősorban azt kell leírni, hogy:
- egy absztrakciós szinten megvalósított csíkozás és tükrözés (több diszken is tárolja ugyanannak az adatnak egy-egy példányát, és az egészet csíkozza);
- így pl. csinálhatunk páratlan számú diszkből is csíkozott-tükrözött tömböt (RAID0+1 és RAID1+0 csak páros számú diszkkel megy);
- lehet hozzá hotspare-t adni;
- paraméter: hány éles diszk (ami nem spare), hány near másolat, hány far másolat, hány spare.
(A near/far magyarázatát l. a Software RAID Linux alatt szócikkben.)
Egy válasz a zh-ból (betű szerint):
Egy absztrakciós szinten megvalósított RAID1 és RAID0. A tömb hotspare-t tartalmaz, bővíthető, a hibajavítást megvalósító paritás "tömbök" nem külön meghajtón helyezkednek el, ezek ugyanúgy az adatok mellett szerepelnek. A RAID0 a diszkek csíkozását, a RAID1 a diszkek tükrözését jelent. Csíkozás alatt az értendő, hogy a több diszkből álló tömb teljes területét felhasználjuk, ellenben nem törekedünk az adatok biztonságos tárolására. A csíkok szélesíthetőek több diszk beiktatásával, sekélyíthetőek, mélyíthetőek a csíkonkénti blokkszám csökkentésével, növelésével.
A tükrözés a redundancia növelését szolgálja, az adatok pontos másolata található meg az összes diszken. RAID10 esetén a hotspare bármelyik kiesett lemezt pótolhatja, online képes szinkronizálni. Maximum 2 winchester kiesését képes túlélni.
Kommentár: a válasz sajnos csak 2 pontot ér, mert számos hibát tartalmaz:
- A RAID10 egyelőre nem bővíthető.
- Nincs benne paritás (súlyos hiba paritást emlegetni); a redundanciát másolatok tárolásával biztosítja, mint a RAID1.
- A csíkozás nem azt jelenti, hogy a teljes területet felhasználjuk, hanem azt, hogy a logikailag folytonos adatterületek több diszkre vannak elosztva annak érdekében, hogy a folytonos írás/olvasás több diszket is érintsen, és így ezek a műveletek gyorsuljanak.
- A csíkozás nem zárja ki, hogy a biztonságra is figyeljünk: a RAID5 is csíkoz, csak számol paritást is.
- A RAID10 annyi diszk kiesését képes elviselni, ahány redundáns másolatot tartalmaz, ez viszont egy olyan paraméter, amit a tömb létrehozásakor állíthatunk be.
- Nem tér ki a near és far másolatokra.

8 Logikai kötetkezelés

  • Hogyan lehet az LVM segítségével online mentést nem támogató adatbázisról mégis kvázi-online mentést készíteni? (10 pont)
Helyes válasz:
1. Leállítjuk az adatbázist – ami az adatokat egy logikai köteten tárolja –, vagy legalábbis befagyasztjuk a tranzakciókat, hogy rövid időre konzisztens állapotban maradjanak a diszken tárolt adatok.
2. Készítünk egy pillanatfelvételt (LVM snapshotot) az adott logikai kötetről. Ez nagyon gyorsan megvan.
3. Az adatbázist újraindítjuk, vagy újra engedélyezzük az író tranzakciókat.
4. Ezután az LVM a snapshot copy-on-write szemantikájának köszönhetően, ha az adatbázisszoftver ír az eredeti kötetre, akkor a módosítandó adatoknak egy másolatát elhelyezi a snapshot-köteten, így biztosítva, hogy onnan mindig kiolvasható legyen a snapshot készítésekori állapot.
5. Ezután a kedvenc offline backup-megoldásunkkal lementjük a snapshot-kötetről az adatbázist.
Így megoldható, hogy az adatbázist ne kelljen annyi időre leállítani, ameddig az offline mentés tart, csak a snapshot létrehozásának idejére, ami max. tizedmásodperces nagyságrendű idő.
Egy válasz a zh-ból (betű szerint):
LVM-el lehet snapshotot ???? ez csak a ????változtatásokat???? ???? le mivel ez kell vissza????.
Kommentár: a válasz az olvashatatlan szavaktól függetlenül 1 pontot ér, mivel csak a snapshotot, mint kulcsfogalmat említi, a módszer részleteiről egyáltalán nem emlékezik meg.

  • Legfeljebb mennyi helyet érdemes allokálni egy snapshot LV számára? Miért? (3 pont)
Helyes válasz:
Legfeljebb annyit, amekkora az eredeti LV (aminek a snapshotja), mégpedig azért, mert a snapshot csak azokat az adatokat tárolja, amelyek az eredeti köteten megváltoztak, ennek a tárolásához pedig nem lehet szükség több helyre, mint amekkora az eredeti kötet (x MiB-nyi adatban legfeljebb x MiB-nyi változás tud bekövetkezni).
Egy válasz a zh-ból (betű szerint):
Legfeljebb annyit, amekkora a volume, amiről a snapshot készül, ez általában sok, helyette elég annyi, amennyi változásra számítunk az adott volume-on a snapshot használata alatt (a volume változhat, de a snapshot megőrzi a volume eredeti állapotát, ha a snapshotot nem változtatjuk, így az eredeti állapotnak változáskor ki kell íródnia a snapshotra).
Kommentár: a válasz 3 pontot ér; az indoklás ugyan nem szabatos, de a kérdés szempontjából irreleváns kiegészítésből kiderül, hogy a hallgató érti, miről van szó.

9 A bootfolyamat

  • Miért nehéz a System V init használata esetén egy daemonizált szolgáltatás megbízható, robusztus leállítása? Milyen módszerrel próbálják enyhíteni a problémát, és mi a baj ezzel a módszerrel? Hogyan foglalná össze, mi a probléma gyökere? (12 pont)
Helyes válasz:
A daemonizálódás azt jelenti, hogy amikor a szolgáltatás elindul, az első processz szinte azonnal indít egy gyermekfolyamatot (ami nyit egy új process groupot), majd kilép. A szolgáltatás nyújtásáért a továbbiakban ez a gyermekfolyamat, ill. az ő esetleges gyemekfolyamatai a felelősek; az első processzt indító folyamatnak a továbbiakban nincs kapcsolata a szolgáltatásért felelős processzekkel, mert az ő gyermekfolyamata szinte azonnal kilépett, és a Unixban minden processz csak a közvetlen gyermekfolyamatai állapotáról értesül hivatalból.
Ennek a következménye az, hogy nincs pontos képünk arról, melyik PID-hoz tartozó processz a felelős egy szolgáltatásért.
A szolgáltatás leállítása általában abból áll, hogy a megfelelő processznek küldünk egy bizonyos signalt. A gond az, hogy nem tudjuk, melyik a megfelelő processz. Többféle heurisztikával meg lehet próbálni megkeresni, de mindegyikkel van valami baj.
- Kereshetünk adott nevű processzt. Ez nem jó, mert a szolgáltatásunkkal nem összefüggő processznek is lehet olyan neve, ill. elképzelhető, hogy a szolgáltatásunkkal kapcsolatos processz neve nem kiszámítható (mert mondjuk átírja aszerint, hogy éppen mit csinál).
- Hálózati szolgáltatás esetén megnézhetjük, melyik processz figyel az adott szolgáltatás portján. Ezzel az a baj, hogy elképzelhető, hogy több olyan szolgáltatásunk is van, ami az adott porton figyelni tud; lehet, hogy hol az egyik fut, hol a másik, vagy az egyiket nem is használjuk szolgáltatásként, csak valamilyen segédprogramja miatt van fent, stb. stb.; ilyenkor, ha egy nem futó szolgáltatást próbálunk leállítani, lehet, hogy a futót állítjuk le véletlenül.
- A legelterjedtebb módszer a pidfile használata. Ez egy szövegfile, amibe a szolgáltatás (vagy az őt indító és daemonizáló segédprogram, pl. a start-stop-daemon) beleírja a PID-ját. Ezzel több baj is van:
- Ha a szolgáltatás több processzből áll, és ezeknek van életciklusa (tehát egy idő után kilépnek, és új veszi át a helyüket), akkor elképzelhető, hogy a pidfile már nem a megfelelő PID-t tartalmazza.
- Ha a pidfile helyét egy konfigurációs fájlban kell megadni, elképzelhető, hogy a szolgáltatás elindítása óta megváltozott a konfiguráció, és nem arra a pidfile-ra hivatkozik, amit a futó szolgáltatáspéldány használ.
- Összetett struktúrájú konfigurációs fájl esetén esetleg nem triviális megtalálni benne az érvényes pidfile-beállítást (pl. apache2).
- Így aztán, ha a pidfile-ból ki is olvasunk egy természetes számot, valahogyan meg kell(ene) győződni arról, hogy az valóban a leállítandó szolgáltatáshoz tartozó processz PID-ja-e; itt viszont versenyhelyzetbe kerülhetünk, mert a szám kiolvasása, hitelesítése és a signal elküldése között megeshet, hogy az eredeti processz kilép, és másik kapja meg a PID-ját, így annak a másiknak küldjük a signalt is.
- Még akkor is fennáll ugyanez a versenyhelyzet, ha nem hitelesítjük a PID-t sehogy (ez amúgy rossz ötlet), mert a kiolvasás-signalküldés nem atomi művelet (a kiolvasás után - de a signalküldés előtt - eltűnhet az eredeti processz és létrejöhet ugyanolyan PID-val másik, de még az is baj, csak kisebb, ha csak az eredeti tűnik el).
A probléma gyökere az, hogy az első processzt hagytuk kilépni. Ha ő még futna, akkor a szülője tudná a PID-ját, és így tudna neki signalokat küldeni PID-lottó nélkül is.
Egy válasz a zh-ból (betű szerint):
A System V init a processzeket a process ID-jük (PID) alapján állítja le. Ez azért lehet problémás, mert a PID fájlba bárki beleírhat, más processzt állíthatunk le. Ha a processz kilépett és más kapta meg a PID-jet, akkor is mást állíthatunk le. System V init esetén a démonizált szolgáltatások indítása a következőképpen történik: a processz elindul, háttérbe kerül, majd minden hívásra gyermekfolyamatokat hoz létre. Ez azért nem jó mert nem tudjuk ekzaktul (sic) meghatározni a keresett gyermekfolyamat PID-jét. Ez kiküszöbölhető úgy, hogy a szülő folyamat nem kerül háttérbe és ő foglalkozik minden kéréssel. Ezt valósítja meg a runit és a daemontools.
Kommentár: a válasz sajnos csak 3 pontot ér; nagyon zavaros, sokminden keveredik benne (úgy látszik, ezt rosszul mondtam el az előadáson). Konkrét hibák:
- Ha signalt kell küldeni egy szolgáltatás leállításához, akkor szükségszerűen tudnunk kell egy PID-t, aminek a signalt küldhetjük. Ez nem egyedül a System V initre jellemző.
- Nem derül ki, mi a pidfile.
- Az nem igaz, hogy a pidfile-t bárki felülírhatná; nem szükséges, hogy mindenki számára írható legyen.
- A daemonizálás folyamatának leírása nem jó; nem az a processz kerül a háttérbe, amit közvetlenül elindítunk (pl. a parancssorból), hanem annak a gyermekfolyamata. Amit elindítunk, az a gyermekfolyamat létrehozása után ki is lép.
- Nem szükségszerű, hogy egy daemon egyáltalán foglalkozzon "kérésekkel" (gondoljunk pl. az auto-nice-daemonra). Az pedig pláne nem szükségszerű, hogy minden kérés kiszolgálásához új processz induljon.
- Nem az a baj, hogy az egyes kérésekkel foglalkozó gyermekfolyamatok PID-ját nem tudjuk, hanem az, hogy egyáltalán semmilyen, a szolgáltatáshoz köthető PID-t nem tudunk, legalábbis nem megbízható módon.
- Teljesen független egymástól az, hogy egy szolgáltatás daemonizálódik-e, és hogy külön gyermekfolyamatot indít-e minden kérés kiszolgálásához. Emiatt a leírt, a runitnak tulajdonított megoldás sajnos szintén nem jó.

10 A runit működése

  • Mik az előnyei a runitnak a hagyományos System V inittel szemben? Mik a hátrányai? (12 pont)
Helyes válasz:
Előnyök:
A runit több egyszerű (ezért kisebb erőforrásigényű és várhatóan kevesebb hibát tartalmazó) programmal oldja meg azt, amit az init egy bonyolult programmal.
A bootfolyamat jelentősen felgyorsulhat, mert a szolgáltatások egyszerre indulnak el.
A szolgáltatások közötti függőségek kezelése kézimunkával megoldható (System V init esetén csak kísérletezni lehet vele, robusztus megoldás nincs).
Menedzseli is a szolgáltatásokat, nemcsak elindítja: újraindítja őket, ha leállnak; küldhetünk nekik signalokat; kapunk hozzájuk robusztus naplózást.
(Az inittel is lehet újrainduló szolgáltatást csinálni - "respawn" -, de az nem állítható le szelektíven.)
A szolgáltatások leállításához nem szükséges PID-k megtippelése; mivel a szolgáltatás szülőfolyamata nem lép ki, mindig tudjuk, milyen PID tartozik a szolgáltatáshoz.
A szolgáltatások egységes környezettel indulnak, attól függetlenül, hogy parancssorból indítjuk őket vagy a bootfolyamat során indulnak el.
Tetszőleges számú és nevű runlevelünk lehet.
Ezeket az előnyöket a felhasználók saját szolgáltatásainak is tudjuk biztosítani.
A szolgáltatásokat, ha akarjuk, kiemelt csoportok vagy felhasználók root jogok nélkül is menedzselhetik, akkor is, ha a szolgáltatás root jogokkal fut; ehhez csak a szolgáltatáshoz tartozó runsv-parancs-FIFO-t kell a megfelelő csoport vagy felhasználó számára írhatóvá tenni.
Könnyen le tudjuk kérdezni a szolgáltatásaink státuszát (fut, nem fut, próbál elindulni, mióta fut, mióta nem fut stb.).
Kapunk olyan eszközöket (elsősorban a chpst-t), amikkel egyszerűen beállíthatjuk a futtatandó szolgáltatás unixos állapotterét az elindítása előtt.
Runlevel-váltáskor (a previous symlink segítségével) könnyen nyomon követhetjük, leálltak-e már az előző runlevelben igen, de az újban nem futó szolgáltatások.
Hátrányok:
Általában nem kapunk kész run-scripteket a szolgáltatásokhoz, ezeket nekünk kell megírnunk; így valamivel több munka van a runittal, mint az inittel.
Nincs egységes mechanizmus a szolgáltatások konfigurációjának újraolvastatására (ami az initben a /etc/init.d/szolgáltatásneve reload).
Ha blokkolódik a naplózás, blokkolódik a szolgáltatás (ez elkerülhető, de akkor viszont lehet, hogy elvesznek naplóüzenetek).
Általában nem a runit az alapértelmezés, így a rá való áttéréshez szükséges idő hozzáadódik a telepítés időigényéhez.
(Feltehetően lehet még találni előnyöket és hátrányokat is.)
Egy válasz a zh-ból (betű szerint):
runit előnyei:
- egy dologgal foglalkozik egy parancs, nem sokkal mint az init
- ha egy folyamat megáll újra tudja indítani
- nem probléma, hogy melyik processznek kell a signált küldeni
- kicsik a programok
- gyors
runit hátrányai:
- nem használják a distribek default az init helyett
- a szolgáltatások elindításához nekünk kell megírni a scripteket
- kicsit trükközni kell a runlevel váltásnál, bár a runlevel váltást nem nagyon használják
Kommentár: a válasz 7 pontot ér, mivel hét valódi előnyt/hátrányt említ. A runlevel-váltásra vonatkozó megjegyzés nem állja meg a helyét; nem kell "trükközni" runlevel-váltáshoz, egyszerűen más a mechanizmus, mint az initben. Egy (opcionálisan két) symlink átállítása nem "trükközés" ahhoz képest, hogy kiadjuk a "telinit x" parancsot. A previous symlink nem szükséges a runlevel-váltáshoz a runitban, csak nekünk segítség, hogy nyomon követhessük az előző runlevelben igen, de az újban nem futó szolgáltatásaink státuszát. Az initben ezzel ekvivalens mechanizmus amúgy egyáltalán nincs.

  • Milyen esetekben rotálja a logokat az svlogd? (6 pont)
Helyes válasz:
A következő három esetben:
1. a log mérete elérte a configban megadott számú bájtot.
2. a log életkora elérte a configban megadott számú másodpercet, és a log nem üres.
3. az svlogd processz ALRM signalt kap, és a log nem üres.
Egy válasz a zh-ból (betű szerint):
svlogd: - ha a megadott paramétereket elérték a logok (méret, darabszám, időtartam stb.); a konfigfile-ban állítható be
- ha manuálisan megkérjük erre szignállal
Kommentár: a válasz 4 pontot ér, mivel gondolkodáshiányra utaló dolgot tartalmaz: a logok darabszáma nem lehet a rotálás feltétele, hiszen a rotálás megnöveli a logok számát, tehát ha egyszer túlléptük a küszöböt, akkor folyamatosan rotálnunk kellene. Másfelől viszont a logok darabszámát csak a rotálás növeli meg, tehát ha csak darabszám alapján akarnánk rotálni, akkor sosem rotálnánk. Emellett a válasz nem tér ki arra, hogy üres logot az svlogd semmiképpen nem rotál.

11 Naplózás

  • Mik az előnyei/hátrányai az UDP ill. a TCP fölötti hálózati naplózásnak? (4 pont)
Helyes válasz:
Mivel a TCP kapcsolatorientált, a naplózószerver elvileg túlterhelhető kapcsolatokkal.
Mivel a TCP-ben van torlódásvezérlés, elképzelhető, hogy a naplóüzeneteket író programok blokkolódnak arra várva, hogy a helyi üzenetpuffert hálózaton át üríteni lehessen; ha nem ezt várják meg, egy idő után megtelik a memória a pufferrel vagy elküldés nélkül el kell dobni üzeneteket.
A TCP-kapcsolatok szemantikájának megvalósítása növeli a naplózókliens összetettségét; kezelni kell pl., ha megszakad a hálózati kapcsolat.
Az UDP kapcsolatmentes, "fire and forget" jellegű. Emiatt kliensoldalon nem feltétlenül van visszajelzés arról, hogy egy üzenet elküldése sikeres volt-e, vagyis hálózati problémák esetén naplóüzenetek elveszhetnek útközben.
A torlódásvezérlés hiánya miatt elvileg előfordulhat, hogy az UDP-s naplóüzenetek telítik a hálózatot.
A TCP-kapcsolatok viszonylag egyszerűen biztonságossá tehetők SSL/TLS használatával; elterjedt, szabványos UDP fölötti alkalmazási rétegbeli titkosító-hitelesítő technológia nincs.
UDP-csomagot könnyebb hamisítani, mint TCP-t (amihez session spoofing is kell), így könnyebb hamis naplóüzenetet küldeni UDP-n.

(Erre a kérdésre az a hallgató, akinek a zh-jában szerepelt, nem válaszolt.)

12 Tűzfalak

  • Hasonlítsa össze a DROP és a REJECT iptables-akció működését! Mikor és miért érdemes vagy lehet az egyiket vagy a másikat használni? Mondjon példákat! (6 pont)
Helyes válasz:
A DROP eldobja a csomagot; a REJECT szintén eldobja a csomagot, de erről értesíti a csomag feladóját egy ICMP-üzenettel vagy (választhatóan) egy TCP RST csomaggal. TCP RST csomagot értelemszerűen csak TCP-csomagra tudunk válaszolni; ICMP-csomagra pedig egyáltalán nem válaszolhatunk, nehogy visszacsatolt hurok képződhessen.
A REJECT előnye az, hogy a távoli gép megtudja, hogy a csomagja nem elveszett, hanem nem kértük, így esetleg nem próbálkozik feleslegesen újra (meg újra meg újra). Jó példa arra, amikor ez nekünk (a tűzfal üzemeltetőjének) is jó, az auth (ident) szolgáltatás; ha a 113-as TCP portra jövő kapcsolatokat egyszerűen eldobjuk, akkor olyankor, amikor bizonyos szolgáltatásokat (pl. IRC) próbálunk igénybe venni, ki kell várnunk, amíg a távoli szerver feladja a próbálkozásokat az auth porton; míg ha azonnal küldünk TCP RST-t, akkor az első próbálkozás után rájön, hogy nincs azon a porton semmi, és nem kell kivárnunk a félperces nagyságrendű timeoutot.
A REJECT hátránya ugyanakkor, hogy egyrészt elárulja, hogy az adott címen egyáltalán van számítógép, másrészt pedig forgalmat generál, ami felhasználható lehet DoS-támadáshoz. Ezért ügyelni kell arra, hogy a REJECT szabályaink által generált forgalmat rátalimitáljuk.
Másfelől viszont előnye a REJECTnek, hogy nem árulja el, hogy tűzfal védi a gépet: a védett szolgáltatások portjai úgy viselkednek, mintha csakugyan nem futna ott szolgáltatás, nem pedig úgy, mintha szűrnénk az oda irányuló forgalmat. Emellett "jólneveltség" is jelezni, hogy egy szolgáltatás nem elérhető.
A DROPot akkor célszerű használni, ha a bejövő csomag nyilvánvalóan ártó szándékú; pl. egy ismert spammer IP-jéről jövő SMTP-kapcsolatfelvétel. Ha küldünk neki TCP RST-t, azzal megkönnyítjük a dolgát, ha viszont csak eldobjuk a csomagját, akkor egy darabig még lekötjük az idejét, mert esetleg párszor még megpróbálja.
Egy válasz a zh-ból (betű szerint):
DROP: a csomagot eldobjuk, a küldőt nem értesítjük erről. Pl. támadások érzékelésekor célszerű (portscan esetében lelassítja a támadást, ki kell várnia a timeoutot a támadónak).
REJECT: a csomagot eldobjuk, a küldő kap erről értesítést. Ha szeretnénk, hogy a küldő értesüljön a csomag eldobásáról, ez a célszerű.
Kommentár: a válasz csak 3 pontot ér, mivel:
- nem írja le, milyen értesítést küld a REJECT a feladónak;
- nem mond konkrét példát arra, hogy mikor jó REJECT-et használni;
- nem szükségszerűen igaz, hogy portscan esetén a támadónak bármit is ki kellene várnia: megteheti, hogy minden vizsgált portra párhuzamosan elküld egy, majd röviddel később még egy, majd még egy csomagot, aztán csak a beérkező válaszokkal foglalkozik; ahonnan nem jön válasz, arról pedig feltételezi, hogy nem elérhető/szűrve van.

  • Milyen fogalmakkal dolgozik a Linux Netfilter alrendszere? Magyarázza el, melyik micsoda! (8 pont).
Helyes válasz:
Elsősorban a tábla, a lánc, a szabály, az illesztés (match) és az akció (target) fogalmát kell elmagyarázni. Ezt valószínűleg lehetetlen megtenni a csomag útjának valamilyen mélységű ismertetése nélkül. Nem ismétlem meg itt azt, amit a Tűzfalak szócikkben leírtam.
Egy válasz a zh-ból (betű szerint):
Tábla: 3 táblát használ alapesetben a netfilter, filter, nat és mangle. A filter táblába kerülnek a hagyományos értelemben vett csomagszűrőszabályok (a 2.4-es kernel előtti netfilterben tekinthető úgy, hogy csak ez az egy tábla volt), azaz a node számára kimenő, bejövő és áthaladó csomagokra adhatunk meg szabályokat. A nat táblába a hálózati címfordítással kapcsolatos szabályok kerülnek, a mangle táblába pedig a csomagok jelölésével kapcsolatos szabályok.
Lánc: A a táblákban a szabályok láncokra tagolódnak. A beépített láncoknak előre meghatározott szerepük van, a felhasználók által létrehozott láncok általában valamelyik beépített láncra hivatkoznak. Pl. a filter tábla beépített láncai az INPUT, az OUTPUT és a FORWARD, amik rendre a bejövő, a kimenő, és a node-on áthaladó csomagokra hivatkoznak.
cél (target): a csomagok célja, azaz megadja, hogy az adott szabályra illeszkedő csomaggal mit csináljon a kernel. Ilyen pl. a DROP, ami az adott csomagot eldobja, vagy az ACCEPT, ami elfogadja.
Egy szabály megadása az iptables program segítségével kb. így néz ki: iptables -t tábla -A/D/valami lánc (-p protokoll, -s IP, stb.) -j (vagy -g vagy valami) cél
Kommentár: a válasz 6 pontot ér, mivel nem tér ki a match (illesztés) fogalmára, és kicsit zavarosan ismerteti a láncokat - it jelent az, hogy "a felhasználók által létrehozott láncok valamelyik beépített láncra hivatkoznak"? Éppen fordítva van: a beépített láncokból fogunk elágazni a saját láncainkra, vagyis a beépítettek "hivatkoznak" a felhasználó által definiált láncokra. Van még néhány kisebb pontatlanság (pl. a mangle táblában módosíthatjuk is a csomagokat, nemcsak megjelölhetjük őket; újabban van egy raw tábla is; stb.), de ezek nem fontosak.

13 A munin működése

  • Milyen esetben érdemes COUNTER helyett DERIVE típusúnak definiálni egy adatot a munin (rrdtool) számára, és miért? (4 pont)
Helyes válasz:
(A COUNTER típusú adatról az rrdtool feltételezi, hogy monoton nő; tehát ha az értéke csökkent, akkor egy 32 vagy egy 64 bites számláló túlcsordult.)
(A DERIVE típusú adatnál az rrdtool nem feltételez monotonitást; a kiolvasott érték idő szerinti deriváltját ábrázolja, ami lehet negatív is.)
Akkor érdemes DERIVE-ot használni COUNTER helyett, ha:
- olyan számlálónk van, ami viszonylag gyakran resetelődik anélkül is, hogy túlcsordulna (pl. reboot miatt); de
- nem tudunk vagy akarunk konkrét felső korlátot megadni az általa számolt mennyiség növekedési rátájára (amit az rrdtool a grafikonban ábrázol); viszont
- zavarnak a grafikonokban az rrdtool által feltételezett túlcsordulásokat korrigálni hivatott 232-es tüskék; de
- az nem zavar minket, ha a számláló valódi túlcsordulásakor a grafikonban nem látunk semmit.
A DERIVE-hoz ilyenkor elég egy univerzális, 0-ás alsó korlátot megadni; a COUNTERnek viszont (ha pl. hálózati forgalomról van szó) minden gépen kellhet más korlát (pl. mert mindenhol más az upstream sávszélesség).
Egy válasz a zh-ból (betű szerint):
Ez két különböző számláló típus, akkor érdemes COUNTER helyett DERIVE-ot használni, ha a számláló nem növekedhet minden határon túl.
Kommentár: a válasz sajnos csak 1 pontot ér, mivel nem indokolja meg, hogy miért érdemes DERIVE-ot használni akkor, ha a "a számláló nem növekedhet minden határon túl", ez viszont önmagában érthetetlen. Az egy pont azért jár, mert a hallgató látszólag tisztában van azzal, hogy egyáltalán micsoda a COUNTER és a DERIVE.

14 A Nagios működése

  • Mire és miért kell odafigyelni sok szolgáltatás monitorozása esetén (pl. ötpercenként meg akarunk győződni arról, hogy megy mind a 3000 webszerverünk)? Hogyan oldja meg ezt a problémát a Nagios? (5 pont)
Helyes válasz:
Nagyszámú szolgáltatás monitorozásakor több fontos problémával is szembe kell nézni. Ezek közül az egyik az, hogy a monitorozással kapcsolatos terhelés minél egyenletesebben jelentkezzen, tehát ne egyszerre akarjuk a 3000 webszerver állapotát lekérdezni, mert az ennyire szélsőségesen börsztös forgalmat esetleg nem bírja jól a hálózatunk, és a mérési eredményeket is eltorzíthatja; pl. lehet, hogy azért mérünk rossz reakcióidőt, mert elfogyott a sávszélesség, és nem azért, mert lassú a webszerver. Ezt a problémát a Nagios "okos" ütemezője megpróbálja megoldani, és aránylag egyenletesen elosztani a próbálkozásokat úgy, hogy mindegyikre az előírt gyakorisággal kerüljön sor, de lehetőleg minél kevesebb történjen egyszerre. NEMHASZ: Ne Monitorozzuk Halálra A Szolgáltatásokat.
Egy másik gond forrása az lehet, ha a monitorozó gép hálózati kapcsolata megszakad; ebben az esetben mind a 3000 webszervert egyszerre látja meghibásodni, és mindegyikről szépen küld is emailt, vagy rosszabb esetben sms-t. Ezt a Nagios-szal úgy kerülhetjük el, ha függőségeket vezetünk be a szolgáltatások között; így pl. ha nem látjuk a default gatewayt, csak erről az eseményről kapunk értesítést, és az ettől függő további tesztekre (a 3000 db webszerver ellenőrzésére) sor sem kerül.
Egy válasz a zh-ból (betű szerint):
A monitorozás szempontjából lényeges, hogy ne arról szóljon üzenet a monitorozónak, hogy egy adott szolgáltatás nem megy, hanem arról, hogy működik. A jelzés elmaradása esetén pedig riasszon minket. Fontos szempont, hogy a monitorozás ne vegyen nagyobb mennyiségű erőforrást igénybe,mint az adott szolgáltatás / ez akkor fontos, ha a monitorozás és a szolgáltatás ugyanazokat az erőforrásokat használja / Így a példában szereplő 3000 webszerver egyszerre történő állapotlekérdezése a hálózaton csúcsterhelést jelent. A lekérdezéseket osszuk szét az ötperces időtartamban, így elkerülhetjük a túlterhelést. Ha egyszerre vizsgálnánk az összeset, akkor elképzelhető lenne, hogy a webszerverek pingelése akkora terhelést okozna hálózatunkon, hogy a webszerverek nem lennének elérhetőek.
Kommentár: a válasz 3,5 pontot ér. A két probléma közül az egyiket jól leírja, és a kérdés sajnos olyan értelemben félrevezető volt, hogy egyes számban beszélt "a problémáról", azt a látszatot keltve, hogy csak egy van. A válasz ugyanakkor nem említi, hogy a Nagios képes lenne arra, hogy egyenletesen ossza el a próbálkozásokat; ezen túlmenően webszerverek elérhetőségét nem pingeléssel vizsgáljuk, hanem HTTP-kéréssel (hiába ping, ha az apache lerohadt, ill. a webszerver működhet akkor is, ha pingelni nem tudjuk).
Személyes eszközök