A UNIX alapjai ChrisShumwayÁtdolgozta: Áttekintés Ez a fejezet a &os; operációs rendszer alapvető funkcióit és parancsait mutatja be. Az itt tárgyalásra kerülő anyag nagy része érvényes bármelyik más &unix;-szerű operációs rendszer esetén is. Ezért, ha már ismerjük az említésre kerülő ismereteket, minden további gond nélkül átugorhatjuk ezt a fejezetet. Azonban ha még teljesen ismeretlen számunkra a &os;, minden bizonnyal ez lesz az, amit alaposan át kell majd olvasnunk. A fejezet elolvasása során megismerjük: az ún. virtuális konzolok használatát &os; alatt; hogyan működnek együtt a &unix; állományokra vonatkozó engedélyei a &os; saját kiegészítéseivel; egy &os; állományrendszer alapértelmezett kialakítását; a &os; lemezszervezését; hogyan csatlakoztassunk és válasszunk le állományrendszereket; mik azok a folyamatok, démonok és jelzések; mik azok a parancsértelmezők, és miként tudjuk megváltoztatni az alapértelmezett bejelentkezési környezetünket; hogyan használjuk az alapvető szövegszerkesztőket; mik az eszközök és az eszközleírók; &os; alatt milyen bináris formátumokat használhatunk; szükség esetén hogyan olvassuk el a megfelelő man oldalakat. Virtuális konzolok és terminálok virtuális konzolok terminálok A &os; számos módon használható. Ezek közül az egyik az, ha parancsokat gépelünk be a szöveges terminálon. Így érhető el egyszerűen a &unix; operációs rendszer rugalmasságának és erejének jelentős része. Ebben a szakaszban megtudhatjuk, mik azok a terminálok és konzolok és miként tudjuk ezeket &os; alatt használni. A konzol konzol Ha nem állítottuk volna be, hogy a &os; indulása során automatikusan induljon el a grafikus felület is, akkor a rendszer egy bejelentkező képernyőt fog mutatni közvetlenül a rendszerindítás befejeződése után. Ekkor valami ilyesmit kell majd látnunk: Additional ABI support:. Local package initialization:. Additional TCP options:. Fri Sep 20 13:01:06 EEST 2002 FreeBSD/i386 (pc3.example.org) (ttyv0) login: Egyes rendszereken ugyan némileg eltérhetnek az üzenetek, de hasonlót kell látnunk. Minket most az utolsó két sor érdekel. Az utolsó előtti sorban ez olvasható: FreeBSD/i386 (pc3.example.org) (ttyv0) Ez a sor arról értesít minket, hogy a rendszerünk éppen most indult el: egy &os; konzolt látunk, amely egy &intel; x86 architektúrájú processzoron fut Erre utal pontosan az i386 jelzés. Még abban az esetben is az i386 kiírást fogjuk látni, ha a &os;-t konkrétan nem is az &intel; 386-os processzorán futtatjuk. Itt ugyanis nem a processzorunk típusát, hanem annak architektúráját láthatjuk. . A gépünk neve (mivel minden &unix;-os gép rendelkezik egy névvel) pc3.example.org, és ennek a rendszerkonzolját látjuk most éppen — a ttyv0 terminált. Végezetül az utolsó sor mindig: login: Ez az a rész, ahova a &os;-be történő bejelentkezéshez meg kell adnunk a felhasználói nevünket (user name). A következő szakaszban erről olvashatunk. Bejelentkezés a &os;-be A &os; egy többfelhasználós, többfeladatos rendszer. Így hívják hivatalosan azokat a rendszereket, amelyeket többen tudnak használni és egyetlen számítógépen egyszerre rengeteg programot képesek futtatni. Minden többfelhasználós rendszernek valamilyen módon meg kell tudnia különböztetnie egy felhasználóját a többitől. A &os;-ben (és minden más &unix;-szerű operációs rendszerben) ezt úgy érik el, hogy a programok futtatása előtt minden felhasználónak be kell jelentkeznie a rendszerbe. Minden felhasználó rendelkezik egy egyedi névvel (ez a felhasználói név) és ehhez egy titkos kulcssal (ez a jelszó). A &os; a programok futtatásához ezt a kettőt fogja elkérni a felhasználótól. rendszerindító szkriptek Egyből miután a &os; elindult és befejezte a rendszerindításhoz használt szkriptjeinek lefuttatását A rendszerindító szkriptek olyan programok, amelyek a &os; indulása során maguktól lefutnak. Legfontosabb feladatuk elvégezni a többi program futtatásához szükséges beállításokat, valamint elindítani a háttérben futtatandó, hasznos munkát végző szolgáltatásokat. , ez a kijelzés (vagy más néven prompt) fog megjelenni és kér egy érvényes felhasználói nevet: login: A példa kedvéért most tegyük fel, hogy a felhasználói nevünk pgj. Az iménti prompthoz írjuk be, hogy pgj és nyomjuk le az Enter billentyűt. Ezt követően meg kell jelennie egy másik promptnak is, amely egy jelszót (password) kér: login: pgj Password: Most pedig gépeljük be pgj jelszavát és nyomjunk utána egy Enter billentyűt. Vigyázzunk, hogy a jelszót nem látjuk a beírás során! Emiatt most ne aggódjunk. Ezzel kapcsolatban elegendő csak annyit tudni, hogy mindez biztonsági megfontolásokból történik. Amennyiben jól adtuk meg a jelszavunkat, sikeresen bejelentkezünk a &os; rendszerébe és készen állunk az összes elérhető parancs kipróbálására. Bejelentkezés után a MOTD (message of the day) vagy más néven a nap üzenete jelenik meg, amelyet a parancssor követ (egy #, $ vagy % jel). Innen tudhatjuk meg, hogy sikerült bejelentkeznünk. Több konzol használata A &unix; parancsokat egy konzolon is szépen ki tudjuk adni, de a &os; egyszerre ugyebár több programot is tud futtatni. A parancsok megadásához viszont egyetlen konzol használata elég nagy pazarlás lenne, hiszen egy olyan operációs rendszer mint a &os;, tucatnyi programot képes futtatni egy időben. Ebben az esetben jelenthetnek számunkra segítséget a virtuális konzolok. A &os; beállítható úgy, hogy sok-sok különféle virtuális konzolt ajánljon fel számunkra. A virtuális konzolok között a billentyűzeten a megfelelő gombok lenyomásával tudunk váltani. Mindegyik konzolnak megvan a saját kimeneti csatornája, és a virtuális konzolok közti váltás folyamán a &os; gondoskodik a billentyűzetről érkező bemenet, valamint a monitorra irányított kimenet megfelelő kezeléséről. A konzolok közti váltásra a &os; külön billentyűkombinációkat tart fenn A &os; konzol- és billentyűzetmeghajtóinak teljes, pusztán műszaki és precíz leírása a &man.syscons.4;, &man.atkbd.4;, &man.vidcontrol.1; és &man.kbdcontrol.1; man oldalakon olvasható. Itt most nem bocsátkozunk részletekbe, azonban a téma iránt érdeklődő olvasóknak mindig érdemes fellapozniuk a kapcsolódó man oldalakat, ahol megtalálhatják az említett eszközök részletesebb és bővebb leírását. . A &os;-ben a különböző virtuális konzolok közti váltásra az AltF1, AltF2 billentyűket, az AltF8 billentyűkombinációval bezárólag használhatjuk. A konzolok közti váltogatás során a &os; ügyel a képernyő tartalmának elmentésére és visszaállítására. Ennek eredményeképpen úgy látszik, mintha több virtuális képernyőn és billentyűzeten adnánk parancsokat a &os;-nek. Az <filename>/etc/ttys</filename> állomány A &os; alapértelmezés szerint nyolc virtuális konzollal indul. Ez azonban nem egy előre rögzített érték, hiszen könnyedén testreszabhatjuk úgy a telepített rendszerünket, hogy több vagy esetleg kevesebb virtuális konzollal induljon el. A virtuális konzolok száma és azok pontos beállítása az /etc/ttys állományon keresztül adható meg. A &os; virtuális konzoljait tehát az /etc/ttys állomány megfelelő módosításával tudjuk behangolni. Itt minden egyes olyan sor, amely nem megjegyzés (vagyis azok a sorok, amelyek nem a # karakterrel kezdődnek), tartalmazza az egyes terminálok vagy virtuális konzolok beállításait. Az állomány a &os; telepítésében szereplő, alapértelmezett változata kilenc virtuális konzol konfigurációját tartalmazza, amelyek közül nyolc aktív. Ezek a ttyv résszel kezdődő sorok: # name getty type status comments # ttyv0 "/usr/libexec/getty Pc" cons25 on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure Az állományban található oszlopok kimerítő magyarázatát, illetve a virtuális konzolok beállításához használható kapcsolókat a &man.ttys.5; man oldalon olvashatjuk. Az egyfelhasználós mód konzolja Az egyfelhasználós mód részletes leírása a ban található. Fontos tudni, hogy amikor a &os;-t egyfelhasználós módban futtatjuk, csupán egyetlen konzolunk van, és a virtuális konzolok nem érhetőek el. Egyébként az egyfelhasználós mód erre vonatkozó beállításai is megtalálhatóak az /etc/ttys állományban. Ehhez keressük meg a console kezdetű sort: # name getty type status comments # # Ha a konzolt "insecure" (nem biztonságos) típusúnak választjuk meg, # akkor a használatához az egyfelhasználós mód aktivilásá előtt a rendszer # kérni fogja a rendszeradminisztrátori jelszót. console none unknown off secure A console felett látható megjegyzés jelzi, hogy át tudjuk írni ebben a sorban a secure (biztonságos) értékű paramétert insecure (nem biztonságos) értékűre. Ilyenkor, hogy ha a &os; egyfelhasználós módban indul, kérni fogja a root felhasználó (a rendszeradminisztrátor) jelszavát. Vigyázzunk, amikor ezt az értéket insecure-ra állítjuk! Ha ugyanis véletlenül elfeledkeznénk a root jelszaváról, akkor azzal az egyfelhasználós mód használata is veszélybe kerülhet. Habár ettől függetlenül is lehetséges, azokra számára mégis nehéz helyzetnek bizonyulhat, akik nem mozognak elég otthonosan a &os; rendszerindítási folyamatának és a hozzákapcsolódó programok ismeretében. A videomód váltása konzolban A &os; konzol alapértelmezett videomódja átállítható 1024x768-ra, 1280x1024-re, vagy bármilyen olyan más méretre, amit a videokártyánk és monitorunk képes megjeleníteni. Az eltérő videomódok használatához először újra kell fordítanunk a rendszermagunkat az alábbi két beállítás hozzáadásával: options VESA options SC_PIXEL_MODE Miután a rendszermagot sikeresen újrafordítottuk a fenti beállításokkal, a &man.vidcontrol.1; segédprogrammal tudjuk megállapítani, hogy a hardverünk milyen videomódokat enged használni. Az összes támogatott videomódot a következőképpen tudjuk lekérdezni: &prompt.root; vidcontrol -i mode A parancs eredményeképpen tehát megkapjuk a hardverünk által ismert videomódokat. Ezek közül tudjuk kiválasztani valamelyikőjüket és root felhasználóként a &man.vidcontrol.1; segítségével beállítani: &prompt.root; vidcontrol MODE_279 Ha az új videomód megfelel számunkra, akkor ezt a beállítást az /etc/rc.conf állományon keresztül véglegesíthetjük is: allscreens_flags="MODE_279" Engedélyek UNIX A &os;, mivel a BSD &unix; egyik közvetlen leszármazottja, számos &unix;-os alapötletre épül. Ezek közül az első és talán a leginkább kihangsúlyozott, hogy a &os; egy többfelhasználós operációs rendszer. Egy olyan rendszer, amely egyszerre több, egymástól független feladattal foglalkozó felhasználót képes kiszolgálni. A rendszer felelős a hardveres eszközök, a különféle perifériák, a memória és a processzor idejének minden egyes felhasználó számára szabályos és pártatlan megosztásáért és a feléjük irányuló kérések szervezéséért. Mivel a rendszer több felhasználót is képes támogatni, az általa kezelt erőforrások rendelkeznek engedélyek egy adott halmazával, amelyek eldöntik, ki tudja ezeket olvasni, írni és végrehajtani. Az engedélyek háromszor három bit formájában jelennek meg, amelyek közül az első bitcsoport az állomány tulajdonosára, a második az állomány csoportjára, végül az utolsó pedig a mindenki másra vonatkozó engedélyeket tárolja. engedélyek állományok engedélyei Érték Engedély Könyvtárlistában 0 Nem olvasható, nem írható, nem hajtható végre --- 1 Nem olvasható, nem írható, végrehajtható --x 2 Nem olvasható, írható, nem hajtható végre -w- 3 Nem olvasható, írható, végrehajtható -wx 4 Olvasható, nem írható, nem hajtható végre r-- 5 Olvasható, nem írható, végrehajtható r-x 6 Olvasható, írható, nem hajtható végre rw- 7 Olvasható, írható, végrehajtható rwx ls könyvtárak A &man.ls.1; kapcsolójának segítségével megnézhetjük a könyvtárak tartalmának részletes listáját, amiben megjelennek az állományok tulajdonosaira, csoportjára és a mindenki másra vonatkozó engedélyek is. Például ezt láthatjuk, ha kiadjuk az ls -l parancsot egy tetszőleges könyvtárban: &prompt.user; ls -l total 530 -rw-r--r-- 1 root wheel 512 Sep 5 12:31 egyik -rw-r--r-- 1 root wheel 512 Sep 5 12:31 masik -rw-r--r-- 1 root wheel 7680 Sep 5 12:31 e-mail.txt ... A példabeli ls -l parancs kimenetének első oszlopa így bomlik fel: -rw-r--r-- Az első (bal szélső) karakter mondja meg, hogy ez egy hagyományos állomány, könyvtár, speciális karakteres eszköz, socket vagy bármilyen más különleges pszeudoállomány. Ebben az esetben a - jelzi, hogy egy hagyományos állományról van szó. A következő három karakter, ami ebben a példában az rw-, adja meg az állomány tulajdonosának engedélyeit. Az ezután következő három karakter, az r-- mutatja az állomány csoportjának engedélyeit. Az utolsó három karakter, vagyis itt az r-- adja meg a többiek engedélyeit. A kötőjel arra utal, hogy az adott engedélyű tevékenység nem engedélyezett. Tehát ennél az állománynál az engedélyek a következőek: a tulajdonosa tudja olvasni és írni, a csoportja csak olvasni tudja, ugyanígy bárki más. A fenti táblázatnak megfelelően az állomány engedélyének kódja 644 lesz, ahol az egyes számjegyek jelentik az állomány engedélyeinek három elemét. Ez mind szép és jó, de vajon a rendszer milyen módon kezeli az állományok engedélyeit? A &os; a legtöbb hardveres eszközt állománynak tekinti, amelyeket a programok meg tudnak nyitni, tudnak róluk olvasni és adatokat tudnak kiírni rájuk pontosan úgy, mint bármilyen más állomány esetén. Ezeket a speciális állományokat a /dev könyvtárban találjuk. A könyvtárakat is állományokként kezeli, ezért azok is rendelkeznek olvasási, írási és végrehajtási engedélyekkel. Azonban a könyvtárak végrehajtását engedélyező bit némileg más jelentéssel bír, mint az állományok esetén. Amikor ugyanis egy könyvtárat végrehajthatónak jelölünk meg, az arra fog utalni, hogy bele tudunk lépni, vagyis hogy ki tudjuk rá adni a könyvtárváltás (cd, change directory) parancsát. Ez továbbá arra is utal, hogy az ismert nevű állományokhoz hozzá tudunk férni (természetesen az egyes állományok engedélyeinek megfelelően). A könyvtárak tartalmát ennek megfelelően viszont csak úgy láthatjuk, ha olvasási engedéllyel rendelkezünk a könyvtárra, míg egy általunk ismert állomány törléséhez a tartalmazó könyvtárhoz kell írási és végrehajtási engedélyekkel rendelkeznünk. Ezeken kívül még léteznek további engedélyek is, de ezeket csak olyan különleges esetekben használják, mint például a felhasználóváltó programok (setuid program) vagy a ragadós könyvtárak (sticky directory) létrehozása. Az állományok engedélyeinek behatóbb megismeréséhez és beállításához mindenképpen nézzük át a &man.chmod.1; man oldalt. Szimbolikus engedélyek TomRhodesÍrta: engedélyek szimbolikus A szimbolikus engedélyek (gyakran csak szimbolikus kifejezések) az állományok és könyvtárak engedélyeinek megadása során a számok helyett karaktereket használnak. A szimbolikus kifejezések (ki) (hogyan) (milyen engedélyt) alakúak, ahol az alábbi értékek adhatóak meg: Elem Betű Jelentése (ki) u tulajdonos (ki) g csoport tulajdonos (ki) o egyéb (ki) a mindenki (a világ) (hogyan) + engedély megadása (hogyan) - engedély visszavonása (hogyan) = engedély explicit beállítása (milyen engedély) r olvasás (milyen engedély) w írás (milyen engedély) x végrehajtás (milyen engedély) t ragadós (sticky bit) (milyen engedély) s UID vagy GID állítása Ezek az értékek a &man.chmod.1; paranccsal az eddigiekhez hasonló módon használhatóak, csak itt betűket kell megadnunk. Például az alábbi paranccsal akadályozhatjuk meg, hogy a tulajdonosán kívül bárki hozzáférhessen az ÁLLOMÁNY nevű állományhoz: &prompt.user; chmod go= ÁLLOMÁNY Amennyiben egy állománnyal kapcsolatban több változtatást is el kívánunk végezni, össze tudjuk ezeket fűzni egy vesszőkkel elhatárolt felsorolásban: &prompt.user; chmod go-w,a+x ÁLLOMÁNY A &os; állományjelzői TomRhodesÍrta: A korábban tárgyalt engedélyek mellett még a &os; ismeri az ún. állományjelzők (file flags) beállítását is. Ezek a jelzőbitek egy további biztonsági és irányítási szintet nyújtanak az állományok felett, viszont a könyvtárakra nem vonatkoznak. Ezek az állományjelzők az állományok felett további vezérlést adnak a kezünkbe, aminek révén gondoskodhatunk róla, hogy akár még a root felhasználó (a rendszer adminisztrátora) se legyen képes állományokat eltávolítani vagy módosítani. Az állományjelzők értékei egy egyszerű felületen keresztül, a &man.chflags.1; segédprogrammal változtathatóak meg. Például a következő paranccsal állíthatjuk a rendszer törölhetetlen (undeletable) jelzését az allomany1 állományon: &prompt.root; chflags sunlink allomany1 A törölhetetlen jelzés eltávolításához egyszerűen csak írjuk be az előző parancsot úgy, hogy a sunlink paraméter elejére még beszúrunk egy no szövegrészt. Így: &prompt.root; chflags nosunlink allomany1 Az állományokra éppen érvényes jelzéseket az &man.ls.1; parancs kapcsolójának segítségével jeleníthetjük meg: &prompt.root; ls -lo file1 Ennek megfelelően az eredménynek valahogy így kellene kinéznie: -rw-r--r-- 1 trhodes trhodes sunlnk 0 Mar 1 05:54 allomany1 Sok jelzés csak a root felhasználón keresztül vehető fel vagy távolítható el. Más esetekben viszont az állomány tulajdonosa állíthatja ezeket. A rendszergazdáknak javasoljuk, hogy ezzel kapcsolatban a &man.chflags.1; és &man.chflags.2; man oldalakat tanulmányozzák át. A setuid, setgid és sticky engedélyek TomRhodesKészítette: A korábban említett engedélyeken kívül létezik még további három, amelyekkel minden rendszergazdának illik tisztában lennie. Ezek név szerint a setuid, setgid és sticky típusú engedélyek. Ezek a beállítások bizonyos &unix; műveletek esetén nagyon fontosak, mivel az átlagos felhasználók számára általában el nem érhető funkciók használatát támogatják. A megértésükhöz elsőként a felhasználók valódi és effektív azonosítója közti különbségeket kell tisztáznunk. A valódi azonosító tulajdonképpen az a felhasználói azonosító, amellyel a programot indítjuk el vagy futás előtt birtokoljuk. A program futása közben azonban az effektív felhasználói azonosítóval fut. Például a &man.passwd.1; segédprogram a jelszavát megváltoztatni kívánó felhasználó valódi azonosítójával indul, miközben a jelszavakat tároló adatbázis elérésékor már a root felhasználó effektív azonosítójával fut. Ezáltal a privilégiumokkal nem rendelkező felhasználók is meg tudják anélkül változtatni a jelszavaikat, hogy a Permission Denied hibaüzenettel találkoznának. A &man.mount.8; nosuid beállításával azonban az ilyen típusú binárisok minden különösebb jel nélkül csődöt fognak mondani. Mellesleg a &man.mount.8; man oldala szerint ez az opció nem is teljesen megbízható, mivel nosuid wrapperek segítségével meg lehet kerülni. Ahogy azt az alábbi példa is szemlélteti, a setuid engedélyt a többi elé egy négyes (4) beszúrásával tudjuk beállítani: &prompt.root; chmod 4755 suidexample.sh A suidexample.sh állomány engedélyei ezt követően már így fognak megjelenni: -rwsr-xr-x 1 trhodes trhodes 63 Aug 29 06:36 suidexample.sh Most már jól látható, hogy az állomány tulajdonosához tartozó engedélyek között a végrehajthatóságot szabályozó bit lecserélődött egy s bitre. Ennek köszönhetően a passwd parancshoz hasonló módon kibővített engedélyekkel leszünk képesek futtatni programokat. Két terminál megnyitásával mindezt valós időben is megvizsgálhatjuk. Az egyiken indítsuk el normál felhasználóként a passwd programot. Miközben a program várakozik az új jelszó megadására, a másik terminálon kérdezzük le a programhoz tartozó felhasználói információkat. Tehát az egyik terminálon a következőt látjuk: &prompt.user; passwd Changing local password for trhodes Old Password: Eközben pedig a másikon: &prompt.root; ps aux | grep passwd trhodes 5232 0.0 0.2 3420 1608 0 R+ 2:10AM 0:00.00 grep passwd root 5211 0.0 0.2 3620 1724 2 I+ 2:09AM 0:00.01 passwd A passwd parancsot egyszerű felhasználóként adtunk ki, azonban jól látható, hogy valójában a root felhasználó azonosítójával fut. A setgid a setuid engedélyhez hasonlóan működik, egyedül annyiban tér el, hogy a csoportra vonatkozó beállításokat módosítja. Amikor egy alkalmazást vagy segédprogramot ilyen engedéllyel futtatunk, akkor az adott programot birtokló csoport engedélyeit kapjuk meg. Úgy tudjuk állományokon beállítani a setgid típusú engedélyt, ha az iménti példához hasonlóan a chmod parancs hívásakor még egy kettest (2) írunk az engedélyek elé: &prompt.root; chmod 2755 sgidexample.sh Az így beállított engedélyek az előbbihöz hasonló módon szemlélhetőek meg, azonban ebben az esetben a csoporthoz tartozó engedélyeknél jelenik meg az s bit: -rwxr-sr-x 1 trhodes trhodes 44 Aug 31 01:49 sgidexample.sh Az előbb tárgyalt példákkal kapcsolatban fontos megemlítenünk, hogy habár a szkriptek is végrehajtható állományok, nem fognak a valóditól eltérő effektív felhasználói azonosítóval futni. Ennek oka abban keresendő, hogy a parancssori szkriptek nem hívhatják a &man.setuid.2; rendszerhívást. Ez a két speciális engedély (a setuid és a setgid) a programhoz tartozó engedélyek kiterjesztésével csökkentheti rendszerünk biztonságát. Ezzel szemben viszont a harmadik bemutatandó speciális engedély rendszerünk védelmének erősítésére szolgál: ez az ún. sticky bit. Ha a sticky típusú engedélyt könyvtárra adjuk meg, akkor a benne levő állományok törlését kizárólag azok tulajdonosainak engedi. Ezzel az engedéllyel lényegében a /tmp könyvtárhoz hasonló nyilvános, bárki által elérhető könyvtárakban akadályozhatjuk meg az állományok idegen felhasználók általi törlését. Az engedély beállításához egy egyest (1) kell a többi elé fűznünk, mint például: &prompt.root; chmod 1777 /tmp Most már az ls parancs segítségével láthatjuk ennek a hatását: &prompt.root; ls -al / | grep tmp drwxrwxrwt 10 root wheel 512 Aug 31 01:49 tmp A sticky bit a beállítások végén felbukkanó t révén azonosítható be. A könyvtárak elrendezése könyvtárhierarchia A &os; könyvtárszerkezetének ismerete alapvető jelentőségű a rendszer egészének megértése szempontjából. Ezen belül is a legfontosabb a gyökérkönyvtár, a /. Ez az első könyvtár, amelyet a rendszer a rendszerindítás során csatlakoztat és a többfelhasználós mód előkészítéséhez elegendhetlenül szükséges alaprendszert tartalmazza. A gyökérkönyvtár emellett csatlakozási pontokat szolgáltat a többfelhasználós működésre váltás során csatlakoztatandó további állományrendszerek számára. A csatlakozási pont egy olyan könyvtár, ahová a szülő állományrendszeren (ami gyakran maga a gyökér-állományrendszer) belül további állományrendszereket tudunk beoltani. Erről bővebben a ban olvashatunk. A szabványos csatlakozási pontok: /usr, /var, /tmp, /mnt és /cdrom. Ezekre a könyvtárakra általában az /etc/fstab állományban találunk hivatkozásokat. Az /etc/fstab állomány a rendszer számára a különböző állományrendszerek és a hozzájuk tartozó csatlakozási pontok táblázatát tartalmazza. Az /etc/fstab állományban szereplő legtöbb állományrendszer a rendszerindítás során automatikusan csatlakoztatásra kerül az &man.rc.8; szkriptből, hacsak nem tartalmazzák a beállítást. Ennek részleteit a ban találhatjuk meg. Az állományrendszerek hierarchiájának teljes leírását a &man.hier.7; man oldalon olvashatjuk. Mi egyelőre most megelégszünk a leggyakrabban megjelenő könyvtárak rövid áttekintésével. Könyvtár Mi található itt / Az állományrendszer gyökere. /bin/ Az egy- és többfelhasználós környezetekben is egyaránt alapvető felhasználói segédprogramok. /boot/ Az operációs rendszer indítása során használt programok és konfigurációs állományok. /boot/defaults/ A rendszerindítás alapértelmezett konfigurációs állományai. Lásd &man.loader.conf.5; /dev/ Eszközleírók, lásd &man.intro.4;. /etc/ Rendszerkonfigurációs állományok és szkriptek. /etc/defaults/ Az alapértelmezett rendszerkonfigurációs állományok, lásd &man.rc.8;. /etc/mail/ A &man.sendmail.8; programhoz hasonló levélküldő rendszerek konfigurációs állományai. /etc/namedb/ A named program konfigurációs állományai, lásd &man.named.8;. /etc/periodic/ A &man.cron.8; által naponta, hetente és havonta lefuttatandó szkriptek, lásd &man.periodic.8;. /etc/ppp/ A ppp program konfigurációs állományai, lásd &man.ppp.8;. /mnt/ Egy üres könyvtár, amelyet a rendszergazdák általában ideiglenes csatlakozási pontként használnak. /proc/ A futó programokat tartalmazó állományrendszer, lásd &man.procfs.5;, illetve &man.mount.procfs.8;. /rescue/ Statikusan linkelt programok vészhelyzet esetére, lásd &man.rescue.8;. /root/ A root felhasználó könyvtára. /sbin/ Az egy- és többfelhasználós környezetekben fontos rendszerprogramok és rendszerfelügyeleti eszközök. /tmp/ Átmeneti állományok. A /tmp könyvtár tartalma általában NEM marad meg az újraindítás után. Erre a célra gyakran memóriában létrehozott állományrendszert szoktak csatlakoztatni a /tmp könyvtárba. Ez utóbbit az &man.rc.conf.5; tmpmfs-re vonatkozó változóinak beállításával lehet automatikussá tenni (vagy a /etc/fstab megfelelő módosításával, lásd &man.mdmfs.8;). /usr/ A felhasználói programok és alkalmazások többsége. /usr/bin/ Általános segédprogramok, programozási eszközök és alkalmazások. /usr/include/ Szabványos C include-állományok. /usr/lib/ Függvénykönyvtárak. /usr/libdata/ Egyéb hasznos adatállományok. /usr/libexec/ (Más programok által használt) Rendszerdémonok és rendszereszközök. /usr/local/ A helyi rendszeren telepített programok, függvénykönyvtárak stb. A &os; portrendszere is ezt használja alapértelmezés szerint. A /usr/local könyvtáron belül a &man.hier.7; man oldalon található /usr könyvtár általános felépítése használatos. Ez alól kivételt képez a man alkönyvtár, amely közvetlenül a /usr/local alatt található, nem pedig a /usr/local/share könyvtáron belül, valamint a portok dokumentációja a share/doc/port könyvtárban található. /usr/obj/ A /usr/src könyvtárfában található források fordítása során keletkező architektúrafüggő objektumok. /usr/ports/ A &os; Portgyűjtemény (választható). /usr/sbin/ (A felhasználók által használt) Rendszerdémonok és rendszereszközök. /usr/share/ Architektúrafüggő állományok. /usr/src/ BSD és/vagy helyi források. /usr/X11R6/ Az X11R6 rendszer programjai, függvénykönyvtárai stb. (választható) /var/ Különféle napló, átmeneti, ideiglenes és pufferben tárolt állományok. A memóriában létrehozott állományrendszereket is olykor a /var könyvtárban találjuk. Ezt az &man.rc.conf.5; állományban található varmfs-változók beállításával tehetjük automatikussá (vagy a /etc/fstab megfelelő módosításával, lásd &man.mdmfs.8;). /var/log/ Mindenféle rendszernaplók. /var/mail/ A felhasználók postafiókjait tároló állományok. /var/spool/ A nyomtatók és a levelezés puffereléséhez használt könyvtárak. /var/tmp/ Átmeneti állományok. Az itt található állományok általában megmaradnak a következő rendszerindítás alkalmával is, hacsak a /var nem egy memóriában létező állományrendszer. /var/yp A NIS állományai. A lemezek szervezése Az állománynév a legkisebb szervezési egység, amin keresztül a &os; képes megtalálni az állományokat. Az állományok neveiben a kis- és nagybetűt megkülönböztetjük, tehát a readme.txt és a README.TXT elnevezés két különböző állományra utal. A &os; nem az állományok kiterjesztése (ami a konkrét példánkban a .txt volt) alapján dönti el, hogy az adott állomány vajon program, dokumentum vagy valamilyen más fajtájú adat. Az állományok könyvtárakban tárolódnak. Egy könyvtár lehet akár üres (nincs benne egyetlen állomány sem), vagy többszáz állományt is tartalmazhat. Egy könyvtár ráadásul további könyvtárakat is tárolhat, és így az egymásban elhelyezkedő könyvtárak segítségével könyvtárak egy hierarchiáját tudjuk felépíteni. Ezzel sokkalta könnyebben szervezhetővé válnak az adataink. Az állományokat és könyvtárakat úgy tudjuk elérni, ha megadjuk az állomány vagy a könyvtárt tároló könyvtár nevét, amit egy perjel, a / követ, valamint így összefűzve az eléréshez szükséges további könyvtárak felsorolása. Tehát, ha van egy ize nevű könyvtárunk, amelyben található egy mize könyvtár, amelyen belül pedig egy readme.txt, akkor ennek az állománynak a teljes neve, vagy másképpen szólva az elérési útja ize/mize/readme.txt lesz. A könyvtárak és az állományok egy állományrendszerben tárolódnak. Minden állományrendszer pontosan egy könyvtárat tartalmaz a legfelső szintjén, amelyet az adott állományrendszer gyökérkönyvtárának nevezünk. Ez a gyökérkönyvtár tartalmazhat aztán további könyvtárakat. Eddig még valószínűleg minden nagyon hasonló a más operációs rendszerekben tapasztalható fogalmakhoz. Azonban adónak különbségek: például az &ms-dos; a \ jellel választja el az állományok és könyvtárak neveit, miközben a &macos; erre a : jelet használja. A &os; az elérési utakban sem betűkkel, sem pedig semmilyen más névvel nem jelöli meg a meghajtókat. Tehát a &os;-ben nem írhatjuk, hogy a c:/ize/mize/readme.txt. Helyette az egyik állományrendszert kijelölik gyökér-állományrendszernek. A gyökér-állományrendszer gyökérkönyvtárára hivatkoznak később / könyvtárként. Ezután minden más állományrendszert a gyökér-állományrendszerhez csatlakoztatunk. Ennek értelmében nem számít, hogy mennyi lemezünk is van a &os; rendszerünkben, hiszen minden könyvtár egyazon lemez részeként jelenik meg. Tegyük fel, hogy van három állományrendszerünk, hívjuk ezeket A-nak, B-nek és C-nek. Minden állományrendszer rendelkezik egy gyökérkönyvtárral, amely két további könyvtárat tartalmaz: A1-et és A2-t (és ennek megfelelően a többi B1-et és B2-t, valamint C1 és C2-t). Nevezzük A-t a gyökér-állományrendszernek. Ha a könyvtár tartalmának megjelenítéséhez most kiadnánk az ls parancsot, két alkönyvtárat látnánk, az A1-et és A2-t. A létrejött könyvtárfa valahogy így nézne ki: / | +--- A1 | `--- A2 Egy állományrendszert csak egy másik állományrendszer valamelyik könyvtárába tudunk csatlakoztatni. Ezért most tételezzük fel, hogy a B állományrendszert az A1 könyvtárba csatlakoztatjuk. Ezután a B gyökérkönyvtára átveszi a A1 helyét az állományrendszerben, és ennek megfelelően megjelennek a B könyvtárai is: / | +--- A1 | | | +--- B1 | | | `--- B2 | `--- A2 A B1 vagy B2 könyvtárakban található állományok bármelyike innentől kezdve a /A1/B1, illetve a /A1/B2 elérési utakon érhetőek el. Az A1 könyvtárban található állományok erre az időre rejtve maradnak. Akkor fognak újra felbukkanni, ha a B állományrendszert leválasztjuk az A állományrendszerről. Ha a B állományrendszert az A2 könyvtárba csatlakoztatnánk, az iménti ábra nagyjából így nézne ki: / | +--- A1 | `--- A2 | +--- B1 | `--- B2 és ennek megfelelően az előbb tárgyalt elérési utak /A2/B1 és /A2/B2 lennének. Az állományrendszerek egymáshoz is csatlakoztathatóak. A példát ennek megfelelően úgy is folytathatjuk, hogy a C állományrendszert csatlakoztatjuk B állományrendszerben található B1 könyvtárhoz. Ennek eredménye a következő elrendezés lesz: / | +--- A1 | `--- A2 | +--- B1 | | | +--- C1 | | | `--- C2 | `--- B2 Vagy a C állományrendszer az A1 könyvtáron keresztül csatlakoztatható akár közvetlenül az A állományrendszerhez is: / | +--- A1 | | | +--- C1 | | | `--- C2 | `--- A2 | +--- B1 | `--- B2 Az &ms-dos; operációs rendszert ismerők számára ez hasonló lehet a join parancshoz (habár teljesen nem egyezik meg vele). Általában azonban ezzel nem kell törődnünk, hiszen többnyire csak a &os; telepítése során hozunk létre állományrendszereket és választjuk meg a csatlakozási pontjukat. A későbbiekben ez legfeljebb akkor kerül elő ismét, amikor újabb lemezeket adunk hozzá a rendszerhez. Teljességgel megengedhető, hogy elhagyjuk a többit és csak egyetlen óriási gyökér-állományrendszert használjunk. Ennek viszont megvannak a maga hátrányai és az egyetlen előnye. Több állományrendszer használatának előnyei A különböző állományrendszereknek különböző csatlakoztatási beállításai (mount options) lehetnek. Például, ha kellően elővigyázatosak akarunk lenni, a gyökér-állományrendszer írásvédett módon is csatlakoztatható, aminek köszönhetően lehetetlenné válik a rendszer számára fontos állományok véletlen törlése vagy felülírása. Ha elkülönítjük a felhasználók számára írható állományrendszereket (például a /home könyvtárakat) a többi állományrendszertől, lehetővé válik számunkra, hogy nosuid beállítással csatlakoztassuk ezeket. Ez a beállítás megakadályozza, hogy ezekben a suid/guid bitekkel rendelkező végrehajtható állományok használhatóak legyenek, ezáltal növeli a rendszer biztonságosságát. A &os; az állományrendszer használatától függően magától határoz a benne található állományok optimális kiosztását illetően. Így tehát a gyakorta módosított, kisebb állományokat tartalmazó állományrendszerek esetén teljesen más technikákat alkalmaz, mint például a nagyobb, kevésbé változó állományok esetén. Azonban egyetlen állományrendszer használatával ez a gyorsítási módszer odavész. Noha a &os; állományrendszerei nagyon jól tűrik a hirtelen áramkimaradásokat, egy döntő ponton bekövetkező váratlan leállás mégis kárt okozhat a szerkezetükben. Ha azonban több állományrendszerre osztjuk a tárolandó adatainkat, sokkal valószínűbbé válik, hogy egy ilyen eset után a rendszerünk talpra tud állni, és szükség esetén nekünk is könnyebb lesz a biztonsági mentéseinkből helyreállítani a sérült állományokat. Egyetlen állományrendszer használatának előnyei Az állományrendszerek mérete rögzített. Miután a &os; telepítése során létrehoztunk egy adott méretű állományrendszert, előfordulhat, hogy később szükségünk lesz a méretének növelésére. Ilyenkor nehezen kerülhetjük el az ilyenkor szokásos teendőket: biztonsági mentés készítése, az új méretnek megfelelő állományrendszer létrehozása, majd ezután a lementett adataink visszaállítása. A &os;-ben azonban megtalálható a &man.growfs.8; parancs, amelynek segítségével az állományrendszerek mérete használat közben növelhető, és ezzel megszűnik a méretre vonatkozó korlátozás. Az állományrendszerek partíciókban tárolódnak. A &os; &unix;-os eredete miatt azonban ez a kifejezés nem a hétköznapi partíció jelentését takarja (mint például egy &ms-dos; partíció). Minden partíciót egy betű azonosít a-tól h-ig. Mindegyik partíció csak egyetlen állományrendszert tartalmazhat, aminek révén az állományrendszereket vagy az állományrendszerek hierarchiájában található csatlakozási pontjukkal vagy pedig az ezeket tartalmazó partíció betűjével azonosíthatjuk. A &os; ezeken felül külön lemezterülen tárolja a lapozóállományt (swap space). A lapozóállományt használja a &os; virtuális memória (virtual memory) megvalósításához. Ennek köszönhetően a számítógép képes úgy viselkedni, mintha jóval több memóriával rendelkezne, mint valójában. Így, amikor a &os; kifogy a memóriából, egyszerűen kirakja a memóriából a lapozóállományba az éppen nem használt adatokat, majd amikor ismét szüksége lesz rájuk, visszatölti ezeket (és ilyenkor megint kirak valami mást). Némely partícióhoz kötődnek bizonyos megszokások. Partíció Megszokás a Általában ez tartalmazza a gyökér-állományrendszert. b Általában ez tartalmazza a lapozóállományt. c Mérete általában a tartalmazó slice méretével egyezik meg. Ennek köszönhetően a segédprogramok (például egy hibás szektorokat kereső program) a c partíción keresztül képesek akár az egész slice-szal dolgozni. Normális esetben ezen a partíción nem hozunk létre állományrendszert. d A d partícióhoz egykoron kapcsolódott különleges jelentés, azonban mostanra ez már megszűnt, és a d egy teljesen átlagos partíciónak tekinthető. Minden állományrendszert tartalmazó partíciót a &os; egy ún. slice-ban tárol. A &os; számára a slice elnevezés utal mindarra, amit általában partíciónak neveznek, és ismét megemlítjük, mindez a &unix;-os eredet miatt. A slice-okat 1-től 4-ig sorszámozzák. slice-ok partíciók veszélyesen dedikált A slice-ok sorszáma 1-től indulva az eszközök neve után egy s betűvel elválasztva következik. Így tehát a da0s1 jelentése az első slice lesz az első SCSI-meghajtón. Lemezenként négy fizikai slice hozható létre, de ezeken belül tetszőleges típusú logikai slice-ok helyezhetőek el. Ezen további slice-ok sorszámozása 5-től kezdődik, így ennek megfelelően a ad0s5 lesz az első IDE-lemezen található első kiterjesztett slice. Ezeket az eszközöket foglalják el a különböző állományrendszerek. A slice-ok, a veszélyesen dedikált (Dangerously Dedicated) fizikai meghajtók, és minden más olyan meghajtó, amely partíciókat tartalmaz, a-tól h-ig jelölődnek. Ez a betű az eszköz neve után következik, így ennek megfelelően a da0a lesz az első da meghajtó a, vagyis a veszélyesen dedikált partíciója. Az ad1s3e lesz a második IDE-lemezmeghajtón a harmadik slice-ban szereplő ötödik partíció. Végezetül, a rendszerben minden lemezt azonosítunk. A lemez neve a típusára utaló kóddal kezdődik, amely után aztán egy sorszám jelzi, hogy melyik lemezről is van szó. Azonban eltérően a slice-okétól, a lemezek sorszámozása 0-tól indul. Az általánosan elterjedt kódolások a ban találhatóak. Amikor hivatkozunk egy partícióra, a &os; elvárja tőlünk, hogy nevezzük meg az adott partíciót tartalmazó slice-ot és lemezt is. Emiatt egy partícióra mindig úgy hivatkozunk, hogy először megadjuk a tartalmazó lemez nevét, ettől s-sel elválasztva a tartalmazó slice sorszámát, majd ezt a partíció betűjelével zárjuk. Erre példákat a ban láthatunk. Az érhetőség kedvéért a bemutatja egy lemez kiosztásának fogalmi sablonját. A &os; telepítéséhez először be kell állítani a lemezen található slice-okat, majd létrehozni benne a &os;-hez használni kívánt partíciókat, kialakítani rajtuk az állományrendszereket (vagy a lapozóállományt) és eldönteni, melyik állományrendszert kívánjuk csatlakoztatni. Lemezes eszközök kódjai Kód Jelentés ad ATAPI (IDE) lemez da közvetlen hozzáférésű SCSI lemez acd ATAPI (IDE) CDROM cd SCSI CDROM fd Floppylemez
Példák lemezek, slice-ok és partíciók neveire Név Jelentés ad0s1a Az első IDE lemezen (ad0) levő első slice (s1) első partíciója (a). da1s2e A második SCSI-lemzen (da1) levő második slice (s2) ötödik partíciója (e). Egy lemez kialakításának sablonja Az ábrán a rendszerhez csatlakoztatott első IDE-lemez látható a &os; szemszögéből. Tegyük fel, hogy ez a lemez 4 GB méretű és két, egyenként 2 GB méretű slice-ot (avagy &ms-dos; partíciót) tartalmaz. Az első slice egy &ms-dos; formátumú lemezt foglal magában, a C: meghajtót, illetve a második slice egy telepített &os;-t tartalmaz. Ebben a példában a &os; három adatot és egy lapozóállományt tároló partícióval rendelkezik. A három partíció mindegyikén találhatunk egy-egy állományrendszert. Az a partíció lesz a gyökér-állományrendszer, az e lesz a rendszerünkben a /var és az f pedig a /usr könyvtár. .-----------------. --. | | | | DOS / Windows | | : : > Első slice, ad0s1 : : | | | | :=================: ==: --. | | | a partíció, / | | | > ad0s2a néven hivatkozzuk | | | | | :-----------------: ==: | | | | b partíció, lapozóállomány | | | > ad0s2b néven hivatkozzuk | | | | | :-----------------: ==: | c partíció, nincs | | | e partíció, /var > állományrendszer, az egész | | > ad0s2e néven hivatkozzuk | &os; slice, | | | | ad0s2c :-----------------: ==: | | | | | : : | f partíció, /usr | : : > ad0s2f néven hivatkozzuk | : : | | | | | | | | --' | `-----------------' --'
Állományrendszerek csatlakoztatása és leválasztása Az állományrendszereket legkönnyebben egy-egy faként tudjuk magunk előtt elképzelni, amelyek a / könyvtárból nőnek ki. A /dev, /usr és mellettük szereplő, hozzájuk hasonló összes többi könyvtár csupán egy-egy ág, amelyeknek saját ágaik is lehetnek, mint például a /usr/local és így tovább. gyökér-állományrendszer Különféle okai vannak annak, hogy egyes könyvtárakat különálló állományrendszereken tárolunk. A /var könyvtár tartalmazza a log/, spool/ könyvtárakat és különféle átmeneti állományokat, azonban az ilyen állományok könnyen megszaporodhatnak és megtölthetik az állományrendszert. Mivel a gyökér-állományrendszert nem tanácsos elárasztani mindenféle állománnyal, ezért gyakran a hasznunkra válhat, ha a /var könyvtárat leválasztjuk a / könyvtárból. A másik gyakori ok, ami az imént említett fa egyes ágainak különböző állományrendszereken történő tárolását indokolja, hogy ezek gyakran más fizikai vagy virtuális lemezeken, például a rendszerhez csatlakoztatott Hálózati állományrendszereken vagy éppen CD-meghajtókon találhatóak. Az <filename>fstab</filename> állomány állományrendszerek csatlakoztatás az fstab állománnyal A rendszerindítás folyamata során az /etc/fstab állományban felsorolt állományrendszerek maguktól kerülnek csatlakoztatásra (kivéve amikor a beállítással szerepelnek). Az /etc/fstab állományban található sorok az alábbi szerkezetűek: eszköz /csatlakozási-pont típus beállítások mentésigyak ellszám eszköz A ban leírtak szerint megnevezett (létező) eszköz. csatlakozási-pont Egy (létező) könyvtár, ahova az állományrendszer csatlakozik. típus Az állományrendszer &man.mount.8; parancs szerint ismert típusa. A &os; alapértelmezett állományrendszere az ufs. beállítások Az írható-olvasható állományrendszerek esetén , az írásvédettek esetén pedig , amelyet igény szerint további beállítások követhetnek. A rendszerindítás során automatikusan nem csatlakoztatandó állományrendszerek esetén gyakran alkalmazott beállítás itt még a . Egyéb lehetőségeket a &man.mount.8; man oldalon láthatunk. mentésigyak Ezt általában a &man.dump.8; parancs használja a menteni szükséges állományrendszerek megállapításához. Amennyiben hiányzik ez a mező, az automatikusan a nulla értéket jelöli. ellszám Megadja, hogy mely állományrendszereket kell ellenőrizni. A nullás pass értékkel rendelkező állományrendszerek nem kerülnek ellenőrzésre. A gyökér-állományrendszer (melyet minden más előtt kell ellenőrizni) passno értéke egy, míg az összes többi állományrendszer passno értéke általában egytől különböző. Ha egynél több állományrendszer is ugyanazt a passno értéket kapta, akkor az &man.fsck.8; a lehetőségei szerint megpróbálja ezeket egyszerre ellenőrizni. Az /etc/fstab felépítéséről és a benne használható beállításokról bővebben a &man.fstab.5; man oldalon olvashatunk. A <command>mount</command> parancs állományrendszerek csatlakoztatás Az állományrendszerek tényleges csatlakoztatására avagy mountolására a &man.mount.8; parancs használható. Legegyszerűbb formája: &prompt.root; mount eszköz csatlakozási-pont Ahogy a &man.mount.8; man oldalán is olvashatjuk, itt rengeteg opció is megadható, de ezek közül a leggyakoribbak: Csatlakoztatási opciók Csatlakoztatja az /etc/fstab állományban felsorolt összes állományrendszert, kivéve azokat, amelyek a noauto beállítást tartalmazzák, vagy kizártuk a kapcsolóval, esetleg korábban már csatlakoztattuk. A tényleges csatlakoztatás elvégzése nélkül végrehajt minden mást. Ez az opció leginkább opcióval együtt használható annak megállapítására, hogy a &man.mount.8; valójában mit is akar csinálni. Egy nem tiszta állományrendszer csatlakoztatásának kényszerítése (veszélyes!) vagy egy korábban már csatlakoztatott állományrendszer írható állapotának felfüggesztése. Az állományrendszer írásvédett csatlakoztatása. Megegyezik a opciónál megadható (vagy a &os; 5.2-nél régebbi verziója esetén a ) beállítás használatával. típus Az adott állományrendszert az adott típusnak megfelelően csatlakoztatja, vagy az használata esetén csak az adott típusú állományrendszereket. Az ufs az állományrendszerek alapértelmezett típusa. Frissíti az állományrendszerre vonatkozó csatlakoztatási beállításokat. Részletesebb kijelzés. Az állományrendszer csatlakoztatása írásra és olvasásra. Az opció után vesszővel elválasztott beállításokat adhatunk meg, többek közt az alábbiakat: noexec Az állományrendszeren található állományok végrehajtásának tiltása. Ez egy nagyon hasznos biztonsági beállítás. nosuid Az állományrendszeren nem használhatóak a felhasználó- (setuid) vagy csoportváltásra (setgid) vonatkozó engedélyek. Nagyon hasznos biztonsági beállítás. Az <command>umount</command> parancs állományrendszerek leválasztás Az &man.umount.8; parancs paraméterként egy csatlakozási pontot, egy eszköznevet vagy a , illetve az opciókat várja. A leválasztás kényszerítéséhez mindegyik alakban szerepelhet az opció, valamint a részletesebb kijelzést a opcióval kapcsolhatjuk be. Azonban szeretnénk mindenkit figyelmeztetni, hogy a használata alapvetően nem ajánlott. Az erőszakkal leválasztott állományrendszerek összeomlaszthatják a számítógépet vagy kárt okozhatnak az állományrendszereken található adatokban. Az és opciók használatosak az összes csatlakoztatott állományrendszer leválasztására, amelyek típusait a opció megadása után sorolhatjuk fel. Fontos különbség azonban, hogy az opció a gyökér állományrendszert nem próbálja meg leválasztani. Folyamatok A &os; egy többfeladatos operációs rendszer. Ez azt jelenti, hogy képes látszólag egyszerre több programot is futtatni. Az így egyszerre futó programokat egyenként folyamatoknak (process) nevezzük. Minden kiadott parancsunk elindít legalább egy ilyen folyamatot, és a rendszerünk mozgásban tartásához bizonyos rendszerszintű folyamatok állandóan futnak a háttérben. Minden folyamatot egy folyamatazonosítónak (process ID vagy PID) nevezett szám azonosít egyértelműen, és az állományokhoz hasonlóan, minden folyamatnak van tulajdonosa és csoportja is. A tulajdonos és a csoport ismeretében állapítja meg a rendszer, hogy az adott folyamat a korábban említett engedélyek szerint milyen állományokhoz és eszközökhöz férhet hozzá. Ezenkívül a legtöbb folyamatnak van még egy szülőfolyamata is. A szülőfolyamat az a folyamat, amely az adott folyamatot elindította. Például amikor parancsokat adunk egy parancsértelmezőn keresztül, akkor maga a parancsértelmező is egy ilyen folyamat lesz ugyanúgy, ahogy a benne kiadott parancsok által elindított programok. Ennek megfelelően az így létrehozott összes folyamat szülője maga a parancsértelmező folyamata lesz. Az említettek alól egyik kivétel az &man.init.8; nevű speciális folyamat. Az init lesz a rendszerben mindig az első folyamat, ezért a PID-je is mindig 1. Az init programot a &os; indulásakor a rendszermag fogja automatikusan elindítani. A rendszerben futó programok vizsgálatához két, különösen hasznos parancsot találhatunk: ezek a &man.ps.1; és a &man.top.1;. A ps parancs használatos a pillanatnyilag futó programok statikus listájának megjelenítésére. Ebben olvashatjuk a futó programok azonosítóit, mennyi memóriát használnak éppen, milyen paranccsal indították ezeket stb. A top parancs mutatja az összes aktívan futó programot, majd néhány másodpercenként automatikusan frissíti ezt a listát, aminek révén folyamatosan láthatjuk, miként viselkednek a futó programok. A ps alapértelmezés szerint csupán az általunk futtatott programokat mutatja. Például: &prompt.user; ps PID TT STAT TIME COMMAND 298 p0 Ss 0:01.10 tcsh 7078 p0 S 2:40.88 xemacs mdoc.xsl (xemacs-21.1.14) 37393 p0 I 0:03.11 xemacs freebsd.dsl (xemacs-21.1.14) 48630 p0 S 2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi 48730 p0 IW 0:00.00 (dns helper) (navigator-linux-) 72210 p0 R+ 0:00.00 ps 390 p1 Is 0:01.14 tcsh 7059 p2 Is+ 1:36.18 /usr/local/bin/mutt -y 6688 p3 IWs 0:00.00 tcsh 10735 p4 IWs 0:00.00 tcsh 20256 p5 IWs 0:00.00 tcsh 262 v0 IWs 0:00.00 -tcsh (tcsh) 270 v0 IW+ 0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16 280 v0 IW+ 0:00.00 xinit /home/nik/.xinitrc -- -bpp 16 284 v0 IW 0:00.00 /bin/sh /home/nik/.xinitrc 285 v0 S 0:38.45 /usr/X11R6/bin/sawfish Ahogy az a fenti példában is látszik, a &man.ps.1; kimenete oszlopokra tagolható. Ezek közül a PID tartalmazza a korábban már ismertetett folyamatazonosítókat. Az azonosítók 1-től indulva egészen 99999-ig sorszámozódhatnak, illetve ha kifutnánk belőlük, akkor a számozás kezdődik elölről (azonban a használatban levő azonosítók sosem kerülnek újra kiosztásra). A TT oszlopban láthatjuk azt a terminált, amelyen az adott program éppen fut, de ezt pillanatnyilag akár nyugodtan figyelmen kívül is hagyhatjuk. A STAT oszlopban a program állapotát kapjuk meg, de szintén átugorható. A TIME a program processzoron eltöltött idejét mutatja — ez általában nem arra utal, hogy mennyi ideje fut maga a program, hiszen a legtöbb program sok időt tölt tétlenül, mielőtt egyáltalán szüksége lenne processzora. Végezetül a COMMAND oszlopban olvashatjuk azt a parancsot, amellyel a programot elindították. A &man.ps.1; számos különféle beállítást ismer az általa megjelenített információk megválasztásához. Az egyik ilyen leghasznosabb beállítás az auxww: az segítségével az összes futó programot láthatjuk, nem csak a sajátjainkat; az megadásával láthatóvá válik a folyamat tulajdonosának a felhasználói neve, valamint a memóriahasználata is; az megmutatja a démon (avagy háttér)folyamatok adatait is és a hatására pedig a &man.ps.1; az összes folyamathoz a teljes parancssort kiírja, még akkor is, ha nem férne ki a képernyőre. A &man.top.1; kimenete is hasonló. Ha elindítjuk, általában ezt láthatjuk: &prompt.user; top last pid: 72257; load averages: 0.13, 0.09, 0.03 up 0+13:38:33 22:39:10 47 processes: 1 running, 46 sleeping CPU states: 12.6% user, 0.0% nice, 7.8% system, 0.0% interrupt, 79.7% idle Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free Swap: 256M Total, 38M Used, 217M Free, 15% Inuse PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 72257 nik 28 0 1960K 1044K RUN 0:00 14.86% 1.42% top 7078 nik 2 0 15280K 10960K select 2:54 0.88% 0.88% xemacs-21.1.14 281 nik 2 0 18636K 7112K select 5:36 0.73% 0.73% XF86_SVGA 296 nik 2 0 3240K 1644K select 0:12 0.05% 0.05% xterm 48630 nik 2 0 29816K 9148K select 3:18 0.00% 0.00% navigator-linu 175 root 2 0 924K 252K select 1:41 0.00% 0.00% syslogd 7059 nik 2 0 7260K 4644K poll 1:38 0.00% 0.00% mutt ... A kimenet két részre osztható. A fejlécben (vagyis az első öt sorban) látható az utoljára futtatott program azonosítója (PID), a rendszer átlagos terhelése (load average, amellyel mérjük, hogy a rendszerünk mennyire lefoglalt), a rendszer indítása óta eltelt idő (up mint uptime) és a jelenlegi idő. A fejlécben még megtalálhatjuk azt is, mennyi program fut (esetünkben ez most 47), mennyi memóriát és lapozóállományt használnak, és mennyi időt tölt a rendszer a processzor különböző állapotaiban. A fejléc alatt a &man.ps.1; kimenetéhez hasonló módon oszlopokba rendezve találhatjuk meg a folyamatok adatait: az azonosítóikat, a tulajdonosaik nevét, a felhasznált processzoridőt, a futtatott parancsot. A &man.top.1; alapértelmezés szerint mutatja a futó programok által használt memória mennyiségét is: ez további két oszlopra oszlik, ahol az egyikben a teljes memóriafoglalást (SIZE), a másikban pedig a jelen pillanatban aktívan használt memóriát (RES) láthatjuk. A példában látható is, hogy a &netscape; (navigator-linu) alkalmazásnak majdnem 30 MB-nyi memóriára van szüksége, de ebből aktívan csak 9 MB-ot használ. A &man.top.1; a kijelzést minden második másodpercben magától frissíti, de ez az kapcsolóval állítható. Démonok, jelzések és a futó programok leállítása Amikor elindítunk egy szövegszerkesztőt, nem sok gondunk akad az irányításával, könnyen utasíthatjuk az állományok betöltésére és így tovább. Mindezt azért tehetjük meg, mert a szövegszerkesztő erre lehetőséget biztosít és mivel a szövegszerkesztő egy terminálhoz kapcsolódik. Egyes programok azonban nem úgy lettek kialakítva, hogy állandóan a felhasználó utasításaira támaszkodjanak, ezért az első adandó alkalommal lekapcsolódnak a terminálról. Például egy webszerver egész nap csak webes kéréseket válaszol meg, és általában semmi szüksége nincs a felhasználók utasításaira. A szerverek között leveleket közvetítő programok is ugyanezen osztályba tartoznak. Ezeket a programokat démononoknak hívjuk. A démonok a görög mitológiában jelentek meg: sem a jót, sem pedig a gonoszt nem képviselték, egyszerű apró szellemecskék voltak, akik az emberiség javát szolgálták, pontosan úgy, ahogy ma teszik azt a különféle web- és levelező szerverek. Ezért is ábrázolták sokáig a BSD kabalafiguráját is egy tornacipős, vasvillás vidám démonként. A démonként futó programok nevéhez a hagyományok szerint hozzá szokták fűzni a d betűt. A BIND a Berkeley Internet Name Domain (névfeloldó) szolgáltatása, azonban a hozzá tartozó program neve named, az Apache webszerver programját httpd-nek nevezik, a sornyomtató kezeléséért felelős démon pedig az lpd és így tovább. Ez csupán egy hagyomány, megszokás, nem pedig egy kőbe vésett szabály: például a Sendmail levelező démonának neve sendmail és nem pedig maild. Néha azért szükségünk lehet arra, hogy felvegyük valahogy a kapcsolatot a démonként futó programokkal is. Ennek egyik lehetséges módja a jelzések (signal) küldése (de alapvetően bármilyen futó programnak küldhetünk). Több különféle jelzés küldhető — egyeseknek közülük megkülönböztetett jelentése van, másokat magukat az alkalmazások értelmeznek, amelyről a dokumentációjukban tájékozódhatunk. A &man.kill.1; vagy &man.kill.2; paranccsal más tulajdonában levő futó programoknak nem tudunk jelzéseket küldeni, ami alól egyedüli kivétel a root felhasználó. Bizonyos esetekben a &os; maga is küld néha jelzéseket. Amikor egy alkalmazást rosszul programoznak le és megpróbál egy számára tiltott memóriaterülethez hozzáférni, a &os; küld neki egy Segmentation Violation (SIGSEGV, szegmentálási hiba) jelzést. Ha egy alkalmazás az &man.alarm.3; rendszerhíváson keresztül kér egy adott idő utáni bekövetkező értesítést, akkor kap erről egy Alarm (SIGALRM) jelzést és így tovább. A folyamatok leállítására két jelzés használható: a SIGTERM (befejeztetés) és a SIGKILL (leállítás). A SIGTERM a folyamatok leállításának illedelmes módja, mivel ekkor a futó program képes elkapni ezt a jelzést és észrevenni, hogy le akarjuk állítani. Ilyenkor a leállítás előtt lehetősége van szabályosan lezárni a naplóit és általánosságban véve befejezni mindent, amit éppen csinál. Előfordulhat azonban, hogy a folyamatok figyelmen kívül hagyják a SIGTERM jelzést, ha például éppen egy félbeszakíthatatlan feladat közepén tartanak. A SIGKILL jelzést azonban egyetlen futó program sem hagyhatja figyelmen kívül. Ez lenne a Nem érdekel, mivel foglalkozol, azonnal hagyd abba! jelzés. Amikor SIGKILL jelzést küldünk egy folyamatnak, a &os; leállítja a folyamatot ott és ahol tart Ez azért nem teljesen igaz. Van néhány olyan tevékenység, ami nem szakítható meg. Ilyen például az, amikor a program egy másik számítógépen található állományt próbál olvasni, miközben valamilyen ok (kikapcsolás, hálózati hiba) folytán elveszti vele a kapcsolatot. Ekkor a program futása megszakíthatatlan. Majd amikor a program feladja a próbálkozást (általában két perc után), akkor következik be a tényleges leállítása. . További használható jelzések: SIGHUP, SIGUSR1 és SIGUSR2. Ezek általános célú jelzések, amelyeket az alkalmazások eltérő módokon kezelnek. Tegyük fel, hogy megváltoztattuk a webszerverünk beállításait tartalmazó állományt — valamilyen módon szeretnénk tudatni a szerverrel, hogy olvassa be újra a beállításait. Ezt megtehetjük úgy, hogy leállítjuk és újraindítjuk a httpd démont, de ezzel kiesést okozhatunk a szerver működésében, amit viszont nem engedhetünk meg. A legtöbb démont úgy készítették el, hogy a SIGHUP jelzés hatására olvassa be újra a beállításait tartalmazó állományt. Így a httpd leállítása és újraindítása helyett egyszerűen elegendő egy SIGHUP jelzés küldése. Mivel azonban ez nem szabványosított, a különböző démonok ezt a jelzést többféleképpen is értelmezhetik. Ezért a használata előtt ennek mindenképpen járjunk utána a kérdéses démon dokumentációjában. A jelzéseket a &man.kill.1; paranccsal tudjuk elküldeni, ahogy ezt a következő példában is láthatjuk. Jelzés küldése egy futó programnak Ebben a példában megmutatjuk, hogyan lehet jelzést küldeni az &man.inetd.8; démonnak. Az inetd a beállításait az /etc/inetd.conf állományban tárolja, és az inetd a SIGHUP jelzés hatására képes újraolvasni ezt. Keressük meg annak a folyamatnak az azonosítóját, amelynek a jelzést kívánjuk küldeni. Ezt a &man.ps.1; és a &man.grep.1; használatával tehetjük meg. A &man.grep.1; parancs segítségével más parancsok kimenetében tudunk megkeresni egy általunk megadott szöveget. Ezt a parancsot átlagos felhasználóként futtatjuk, azonban az &man.inetd.8; démont a root birtokolja, ezért az &man.ps.1; használata során meg kell adnunk az kapcsolókat is. &prompt.user; ps -ax | grep inetd 198 ?? IWs 0:00.00 inetd -wW Innen kiderül, hogy az &man.inetd.8; azonosítója 198. Előfordulhat, hogy az eredményben maga a grep inetd parancs is megjelenik. Ez a &man.ps.1; listázási módszere miatt következhet be. A jelzés elküldésére használjuk a &man.kill.1; parancsot. Mivel az &man.inetd.8; démont a root felhasználó futtatja, ehhez először a &man.su.1; parancs kiadásával nekünk is root felhasználóvá (rendszeradminisztrátorrá) kell válnunk. &prompt.user; su Password: &prompt.root; /bin/kill -s HUP 198 Ahogy az a legtöbb &unix; esetén elfogadott, a sikeres végrehajtás esetén a &man.kill.1; sem válaszol semmit. Amikor viszont nem egy saját programunknak akarunk jelzést küldeni, akkor a kill: PID: Operation not permitted (a művelet nem engedélyezett) hibaüzenetet látunk. Ha véletlenül elgépeltük volna a futó program azonosítóját, akkor a küldendő jelzés nem a megfelelő folyamatnál fog kikötni (ami nem éppen jó), vagy ha szerencsénk van, akkor a jelzést egy éppen használaton kívüli azonosítóra küldtük. Az utóbbi esetben a következő láthatjuk: kill: PID: No such process (nincs ilyen folyamat). Miért <command>/bin/kill</command>? A legtöbb parancsértelmező beépítetten tartalmazza a saját kill parancsát, tehát ilyenkor közvetlenül maga a parancsértelmező küldi a jelzést, nem pedig a /bin/kill programon keresztül. Ez gyakran a javunkra válhat, azonban a küldhető jelzések megadása parancsértelmezőnként eltérhet. Így, ahelyett, hogy egyenként ismernünk kellene mindegyiket, sokkal egyszerűbb közvetlenül a /bin/kill ... parancsot használni. A többi jelzés küldése is nagyon hasonló módon történik, hiszen elegendő csupán a TERM vagy a KILL behelyettesítése a parancs megfelelő helyére. A rendszerünkben óvatosan bánjunk a futó programok leállítgatásával, és legyünk különös tekintettel az 1-es azonosítóval rendelkező, speciális feladattal bíró &man.init.8; folyamatra. A /bin/kill -s KILL 1 parancs kiadásával ugyanis gyorsan le tudjuk állítani a rendszerünket. Mielőtt egy &man.kill.1; parancsot lezárnánk az Enter billentyűvel, mindig győződjünk meg róla, hogy valóban tényleg a jó paramétereket adtuk meg. Parancsértelmezők parancsértelmezők parancssor A &os;-ben hétköznapi munkánk legnagyobb részét a parancsértelmezőknek (shell) nevezett parancssoros felületen tudjuk elvégezni. A parancsértelmező fő feladata a beérkező parancsok elfogadása és végrehajtatása. Sok parancsértelmező ezenfelül rendelkezik beépített funkciókkal is, amelyek olyan hétköznapi feladatokban igyekeznek segíteni, mint például az állományok kezelése és tömeges elérése reguláris kifejezések használatával, a parancssor szerkesztése, parancsok makrózása és a környezeti változók használata. A &os; alapból tartalmaz néhány parancsértelmezőt, ilyen például az sh, a Bourne Shell, és a tcsh, a továbbfejlesztett C-shell. Sok más parancsértelmező, mint például a zsh és bash is elérhető a &os; Portgyűjteményéből. De melyik parancsértelmezőt is válasszuk? Ez igazából ízlés kérdése. Ha inkább C programozók vagyunk, akkor valószínűleg egy olyan C-szerű shelllel tudunk kényelmesen dolgozni, amilyen például a tcsh. Ha viszont egy linuxos rendszert használtunk korábban vagy éppen még soha nem használtunk volna a &unix; parancssorát, érdemes a bash-sel megpróbálkoznunk. A lényeg az, hogy minden parancsértelmezőnek vannak olyan egyedi jellemezői, amiért használatóak vagy éppen nem használatóak a munkánkban, ezért magunknak kell kiválasztani a nekünk megfelelőt. A shellek egyik legáltalánosabb jellemzője az állományok neveinek kiegészítése. Miután begépeljük egy parancs vagy állománynév első néhány karakterét, a Tab billentyű lenyomásával megkérhetjük a parancsértelmezőt, hogy magától egészítse ki (találja ki) a fennmaradó részt. Nézzük erre egy példát. Tegyük fel, hogy van két állományunk, izemize és ize.mize, és szeretnénk letörölni az ize.mize nevűt. Ehhez a következőt kell begépelnünk: rm iz[Tab].[Tab]. Erre a parancsértelmező a következő parancsot írja ki: rm ize[SIPOLÁS].mize. A [SIPOLÁS] itt a konzol sípjára vonatkozik, amellyel jelzi, hogy nem tudta teljesen kiegészíteni az állomány nevét, mivel egynél több is megfelel a megadott alaknak. Az izemize és az ize.mize is egyaránt az iz előtaggal kezdődik, azonban ebből a parancsértelmező csak az ize előtagot tudta kikövetkeztetni. Ha most begépelünk még egy . karaktert és újra megnyomjuk a Tab billentyűt, a parancsértelmező ezúttal képes lesz az állomány teljes nevét megállapítani. környezeti változók A parancsértelmezők másik általános jellemzője a környezeti változók használata. A környezeti változók lényegében a parancsértelmező környezetéhez tárolt név-érték párok. Ezt a környezetet látja minden olyan program, amit a parancsértelmezőből meghívunk, és ezért tartalmazni is szokott sok ilyen beállítást. Íme a leggyakoribb környezeti változók felsorolása és rövid leírása: környezeti változók Változó Leírás USER A bejelentkezett felhasználó neve. PATH Vesszővel elválasztott könyvtárak, ahol a parancsértelmező a végrehajtható állományokat keresi. DISPLAY Az aktuálisan használt X11 megjelenítő hálózati neve, amennyiben létezik ilyen. SHELL A használt parancsértelmező. TERM A felhasználó által használt terminál típusa. Ebből a terminál képességeit lehet megállapítani. TERMCAP A terminálok adatbázisából származó, különböző terminálfunkciókhoz tartozó helyettesítő (escape) kódok. OSTYPE Az operációs rendszer típusa, például &os;. MACHTYPE A rendszer alatt futó gép architektúrája. EDITOR A felhasználó által használt szövegszerkesztő. PAGER A felhasználó által lapozásra használt program. MANPATH Vesszővel elválasztott könyvtárak, ahol a parancsértelmező a man oldalakat keresi. Bourne-féle parancsértelmezők A környezeti változók beállítása parancsértelmezőnként valamennyire eltér. Például egy C stílusú parancsértelmező, mint például a tcsh vagy a csh, a setenv paranccsal állítja a környezeti változókat. A Bourne-féle parancsértelmezők, mint például az sh vagy a bash, az export parancsot használják a környezeti változók beállítására. Például a csh vagy a tcsh használata során a következőképpen tudjuk be- vagy átállítani az EDITOR környezeti változó értékét /usr/local/bin/emacs-re: &prompt.user; setenv EDITOR /usr/local/bin/emacs Ugyanez a Bourne-féle parancsértelmezőkben: &prompt.user; export EDITOR="/usr/local/bin/emacs" A legtöbb parancsértelmezőben a nevük előtt szerepeltetett $ jel segítségével kérhetjük a környezeti változók értékének behelyettesítését a parancssorba. Ennek megfelelően az echo $TERM parancs kiíratja a TERM változó aktuális értékét, mivel ebbe a parancsértelmező már az echo meghívása előtt behelyettesíti a TERM értékét. A parancsértelmezők számos speciális karaktert, ún. metakaraktert az adatok különleges reprezentációjaként kezelnek. Köztük a leggyakrabban használt a *, amely tetszőleges számú karaktert helyettesít egy állomány nevében. Az ilyen metakarakterek segítségével tudunk egyszerre több állományt is megnevezni. Például ha begépeljük az echo * parancsot, akkor majdnem ugyanazt kapjuk eredményül, mintha az ls parancsot adtuk volna ki, hiszen a parancsértelmező ilyenkor veszi az összes * metakarakterre illeszkedő állományt, és a kiíratásukhoz pedig rendre behelyettesíti ezeket a parancssorba az echo paramétereként. Ha nem szeretnénk, hogy a parancsértelmező értelmezze a speciális karaktereket, akkor egy backslash (visszaper) (\) karaktert eléjük téve mindezt megakadályozhatjuk. Az echo $TERM parancs ugyebár kiíratja a terminálra vonatkozó környezeti változó beállítását, azonban a echo \$TERM változatlanul kiírja a $TERM szöveget. A parancsértelmezőnk megváltoztatása A parancsértelmezőnk legegyszerűbben a chsh parancs használatával változtatható meg. A chsh kiadása után elindítja az EDITOR környezeti változónak megfelelő szövegszerkesztőt, ha nem lenne ilyen, akkor alapértelmezés szerint a vi hívódik meg. Az így megnyitott állományban változtassuk meg kedvünk szerint a Shell: kezdetű sort. A chsh parancsnak megadhatjuk az opciót is, amin keresztül szövegszerkesztő használata nélkül be tudjuk állítani a parancsértelmezőt. Például ha a parancsértelmezőnket a bash-re akarjuk lecserélni, akkor ezt írjuk be: &prompt.user; chsh -s /usr/local/bin/bash A használni kívánt parancsértelmezőnek szerepelnie kell az /etc/shells állományban. Ha a kiválasztott parancsértelmezőt a Portgyűjteményből telepítettük fel, akkor az már minden bizonnyal bekerült oda. Ha viszont saját magunk raktuk volna fel, akkor ide is fel kell vennünk. Például ha a bash-t manuálisan telepítettük és másoltuk a /usr/local/bin könyvtárba, akkor így kell eljárnunk: &prompt.root; echo "/usr/local/bin/bash" >> /etc/shells Majd próbálkozzunk újra a chsh paranccsal. Szövegszerkesztők szövegszerkesztők szerkesztők A &os; beállításának nagy része szöveges állományok szerkesztésével történik. Emiatt sosem árt legalább egy szövegszerkesztőt ismernünk. A &os; alaprendszerében, valamint a Portgyűjteményben is találhatunk néhányat belőlük. ee szerkesztők ee A legegyszerűbben megtanulható és legkönnyedebb szövegszerkesztőt ee-nek, avagy easy editornak hívják. Az ee indításához írjuk be az ee állománynév parancsot, ahol az állománynév lesz a szerkesztendő állomány neve. Így például az /etc/rc.conf állomány szerkesztéséhez gépeljük be az ee /etc/rc.conf parancsot. Miután elindult az ee, az összes szerkesztéshez használható parancsa megjelenik a képernyő felső részében. Itt a kalap (^) karakter a Ctrl billentyű lenyomására utal, így tehát a ^e jelölés a Ctrle billentyűkombinációt jelenti. Ha ki akarunk lépni az ee-ből, nyomjuk le az Esc billentyűt, majd a felbukkanó menüből válasszuk a szerkesztő elhagyását (leave editor). Ha az állományt módosítottuk, kilépés előtt még a szövegszerkesztő rákérdez, hogy mentse-e a változtatásainkat. vi szerkesztők vi emacs szerkesztők emacs A &os; nagyobb tudású szövegszerkesztőket, mint például a vi-t, is tartalmaz az alaprendszer részeként, miközben a többi, mint például az Emacs vagy a vim a Portgyűjtemény részeként (editors/emacs és editors/vim) érhető el. Ezek a szerkesztők sokkal több lehetőséget és erőt képviselnek, amiért cserébe viszont valamivel nehezebb megtanulni a használatukat. Ha viszont rengeteg szöveget akarunk majd szerkeszteni, akkor egy vim vagy Emacs használatának megismerésével sok időt megspórolhatunk. Számos alkalmazás, amely állományokat akar módosítani vagy szöveges bemenetre van szüksége, automatikusan szövegszerkesztőt nyit meg. Ezt az EDITOR környezeti változó beállításával tudjuk meghatározni. Erről részletesebben a parancsértelmezőknél olvashatunk. Eszközök és eszközleírók Az eszköz elnevezést leginkább a rendszerben folyó, hardverrel kapcsolatos tevékenységek kapcsán használják lemezekre, nyomtatókra, grafikus kártyákra és billentyűzetekre. A &os; indulása során többnyire azt láthatjuk, hogy milyen eszközöket sikerült felismernie. Ezeket a rendszerindításkor megjelenő üzeneteket a /var/run/dmesg.boot állományban nézhetjük meg újra. Például az acd0 az első IDE CD-meghajtót, míg a kbd0 a billentyűzetet képviseli. A &unix; operációs rendszerben a legtöbb eszközt a /dev könyvtárban található, eszközleíróknak (device node) nevezett speciális állományokon keresztül érhetjük el. Eszközleírók létrehozása Amikor egy újfajta eszközt adunk hozzá a rendszerhez vagy csak annak egy új példányát, mindig létre kell hoznunk hozzá egy új eszközleírót. <literal>DEVFS</literal> (DEVice File System, Eszköz-állományrendszer) Az eszközöket tartalmazó állományrendszer, avagy DEVFS, ad hozzáférést a rendszermag által ismert eszközök neveihez a globális állományrendszer nevein keresztül. Így ahelyett, hogy magunknak kellene létrehoznunk és módosítanunk az eszközleírókat, a DEVFS erre a célra fenntart egy külön állományrendszert. A &man.devfs.5; man oldalon olvashatunk bővebben erről. Bináris formátumok Annak megértéséhez, hogy a &os; miért az &man.elf.5; formátumot használja, először is tisztában kell lennünk a &unix; típusú rendszerekben használt végrehajtható állományok három uralkodó formátumával: &man.a.out.5; A legősibb és egyben a klasszikus &unix;-os tárgykódformátum. Egy tömör és rövidke fejlécet használ, aminek az elején a formátum leírására szolgáló bűvös szám található (erről bővebben lásd &man.a.out.5;). Három betöltött szegmenst tartalmaz: .text, .data és .bss, valamint egy szimbólumokat és karakterláncokat tároló táblát. COFF Az SVR3 tárgykódformátuma. A fejléc itt már tartalmaz egy table nevű szegmenst is, tehát a .text, .data és .bss szegmensekhez hasonlóan ebből is többet tud tárolni. &man.elf.5; A COFF után következő formátum, amelyben több szegmens is megtalálható, valamint létezik 32 bites és 64 bites változatban is. Egyetlen hátránya van: az ELF tervezése során rendszerarchitektúránként csupán egyetlen ABI-t (bináris alkalmazói felületet) feltételeztek. Ez azonban meglehetősen helytelen, mivel még a kereskedelmi SYSV világában (ahol már legalább három ABI található: SVR4, Solaris és SCO) sem állja meg a helyét. A &os; ezt a problémát a megbélyegzés (branding) segítségével próbálja megoldani, aminek révén el tudunk látni egy ismert ELF állományt a futtatásához megfelelő ABI-ra vonatkozó információkkal. Erről részletesebben a &man.brandelf.1; oldalán tájékozódhatunk. A &os; a klasszikusok táborából indult, ezért kezdetben az &man.a.out.5; formátumot használta, mivel ez a technológia a BSD kiadások számos generációjában megmérettetett és bevált, egészen a 3.X ág elindulásáig. Habár már jóval előtte lehetett fordítani és futtatni natív ELF binárisokat (és rendszermagokat) a &os; rendszereken, a &os; kezdetben ódzkodott váltani az alapértelmezés szerinti ELF formátumra. De vajon miért? Nos, amikor a Linux-tábor megtette a maga fájdalmas váltását az ELF-re, az nem annyira azért volt, hogy megszabaduljanak az a.out végrehajtható formátumtól, hanem mert a rugalmatlan, ugrótáblákon alapuló oszottkönyvtár-kezelési mechanizmusaik nagyon megnehezítették a gyártók és fejlesztők számára az osztott függvénykönyvtárak létrehozását. Mivel az ELF formátumhoz rendelkezésre álló eszközök megoldást kínáltak az osztott könyvtárak gondjaira, és mivel általánosan elfogadták a jövőbe vezető útként, a &os; is felvállalta az átállással kapcsolatos költségeket és végrehajtotta azt. A &os; az osztott könyvtárakat leginkább a Sun &sunos; rendszeréhez hasonlóan kezeli, ami egy nagyon könnyen használható megoldás. De miért van ilyen sok különböző formátum? A ködös és sötét múltban egyszerűbb hardverek voltak. Ezek az egyszerű hardverek egyszerű, kicsi rendszereket támogattak. Az a.out tökéletesen megfelelő volt egy ilyen egyszerű rendszer (egy PDP-11) binárisainak tárolására. Ahogy az emberek nekiláttak átültetni erről az egyszerű rendszerről a &unix;-ot más rendszerekre, az a.out formátumot továbbra is megtartották, mivel a &unix; kezdeti, Motorola 68k-ra, VAXenre készített átírataihoz is elegendő volt. Ezután néhány éles elméjű hardvermérnök kitalálta, ha rá tudnák kényszeríteni a programokat egy-két ügyetlen trükkre, akkor a terveken meg tudnának spórolni néhány logikai kaput és ezzel a processzor is gyorsabban tudna futni. Miközben az a.out formátumot ilyen hardverre (amit manapság RISC-nek hívnak) is szerették volna áthozni, kiderült, hogy ebben az esetben szinte használhatatlan. Ezért az a.out formátum által felkínáltnál nagyobb teljesítmény elérése érdekében nekiláttak számos más formátumot is kidolgozni. Ekkor jöttek létre a COFF, ECOFF és más hasonló formátumok, amelyek előbb-utóbb korlátokba ütköztek, még mielőtt a történelem megállapodott volna az ELF formátumnál. Ráadásul a programok méretei egyre inkább kezdtek nőni, miközben a lemezek (valamint a fizikai memória) továbbra is viszonylag kicsik maradtak, ezért megszületett az osztott könyvtár ötlete, és a virtuális memóriát kezelő alrendszer is sokat finomodott. Mivel ezek a különböző fejlesztések az a.out formátumra épültek, annak használatósága a beletömött módosítások számával együtt romlott. Emellett az emberek még szerettek volna betölteni különféle dolgokat futási időben dinamikusan, vagy éppen a memória és a lapozóállomány megspórolásához kipucolni a programjaik egyes részeit az inicializáló kódrészletek lefutása után. A programozási nyelvek is fejlődtek, és az emberek a főprogram futása előtt is akartak kódot futtatni. Az a.out formátum rengeteg apró foltozáson esett keresztül, amelyek egy ideig még tudták is tartani magukat. Azonban egy idő után már az a.out formátum egyre növekvő teljesítménycsökkenés nélkül már nem volt képes állni a sarat. Habár az ELF megszüntette a fennálló problémák jelentős részét, egyúttal megnehezítette egy alapvetően működő rendszer leváltását. Ezért az ELF formátumnak meg kellett várnia azt a pillanatot, amikorra az a.out használata már kényelmetlenné vált. Azonban ahogy múlt az idő, az eszközökből, amelyekből a &os; a fordításához szükséges eszközöket származtatta (különösen az assembler és a betöltő),létrejött két párhuzamos fejlesztési fa. A &os;-fa kiegészült az osztott könyvtárak támogatásával és hibákat javított, miközben a GNU-fa alkotói, akik eredetileg készítették ezeket a programokat, újraírták az eszközeiket és a keresztfordításhoz egyszerűbb támogatást készítettek, cserélhetővé tették a különböző formátumokat és így tovább. Sokan akartak &os;-re keresztfordítani, azonban nem volt szerencséjük, mert a &os; régebbi forrásait az as és ld már nem emésztette meg. Az új GNU eszköztár (a binutils) viszont ismeri már a keresztfordítást, az ELF formátumot, az osztott könyvtárakat, a C++ kiterjesztéseit stb. Időközben egyre több gyártó ELF formátumú binárisokat adott ki, és jó érzés volt ezeket &os;-n is futtatni. Az ELF sokkal kifejezőbb az a.out formátumnál, és jóval több bővítési lehetőséget enged az alaprendszerben. Az ELF formátumhoz tartozó eszközöket jobban karbantartják és támogatja a keresztfordítást, ami viszont sokaknak fontos. Az ELF talán némileg lassabb, mint az a.out, azonban ez nehezen mérhető le. Számos részletben eltérnek ugyan, például hogyan képeznek le lapokat, hogyan kezelik az inicializáló kódot stb., de ezek egyike sem igazán fontos. Idővel az a.out támogatása ki fog kerülni a GENERIC rendszermagból, és végül majd teljesen eltávolításra kerül, ahogy a régi a.out formátumú programok szépen lassan kifutnak. Bővebben olvashatunk... Man oldalak man oldalak A &os; legátfogóbb dokumentációja a benne található man oldalak összessége. A rendszerben található szinte majdnem mindegyik programhoz létezik egy rövid használati útmutató, amely bemutatja az adott program alapvető működését és a különböző beállításait. Ezek a leírások a man parancs segítségével jeleníthetőek meg. A man parancs használata egyszerű: &prompt.user; man parancs ahol a parancs a megismerni kívánt parancsra utal. Például ha az ls parancsról szeretnénk többet megtudni, írjuk be: &prompt.user; man ls Az elérhető használati útmutatókat a következő számozott szakaszokra osztották: Felhasználói parancsok Rendszerhívások és hibakódok A C függvénykönyvtár függvényei Eszközmeghajtók Állományformátumok Játékok és egyéb szórakoztató alkalmazások Egyéb információk Rendszerkarbantartási és -működtetési parancsok Rendszermagfejlesztők számára Bizonyos esetekben ugyanaz a téma az útmutatók több szakaszában is elérhető. Például létezik chmod felhasználói parancs és a chmod() rendszerhívás. Ilyenkor a man parancsnak meg tudjuk adni pontosan, melyik szakaszra is vagyunk kíváncsiak: &prompt.user; man 1 chmod Ennek hatására a chmod felhasználói parancshoz tartozó oldal jelenik meg. Írott formában a használati útmutatók különböző szakaszaira hagyományosan a név után zárójelbe tett számmal hivatkoznak, így a &man.chmod.1; a chmod felhasználói parancs és a &man.chmod.2; a rendszerhívás. Ez a módszer remekül működik abban az esetben, amikor ismerjük a parancs nevét, azonban mit tegyünk akkor, ha nem is emlékszünk a nevére? A man parancs a segítségével paraméterezhető úgy is, hogy a parancsok leírásai között keressen valamilyen kulcsszó mentén: &prompt.user; man -k mail Ezzel a paranccsal megkapjuk azon parancsok listáját, amelyek leírásában szerepel a mail kulcsszó. Ez egyébként működésében teljesen megegyezik a apropos paranccsal. Szóval szeretnénk megtudni, hogy a /usr/bin könyvtárban levő parancsok pontosan mit is csinálnak? Ehhez írjuk be: &prompt.user; cd /usr/bin &prompt.user; man -f * vagy &prompt.user; cd /usr/bin &prompt.user; whatis * ami ugyanezt teszi. A GNU info állományok Szabad Szoftver Alapítvány A &os;-ben megtalálható a Szabad Szoftver Alapítvány (Free Software Foundation, FSF) által készített számos alkalmazás. Ezek a programok a szokványos man oldalakon kívül még általában tartalmaznak egy infonak nevezett, sokkal részletesebb hipertext alapú leírást is, amelyeket az info paranccsal, vagy ha van fenn emacs, akkor annak az info módjában tudjuk megjeleníteni. Az &man.info.1; parancs használatához ennyit kell beírnunk: &prompt.user; info Itt a h lenyomásával kapunk egy rövid bemutatkozást. A parancsok rövid listáját a ? billentyű hozza elő.