Eddigi ZH-kérdések
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ék 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.
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.
- - 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). 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 Filerendszerek
- 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.
- 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).
6 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.
7 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.
8 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ő módszer 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.