1 Teljes kéziratok a 20/80 sorozatba Őry Máté Alább közlöm az E-közigazgatási Szabad Szoftver Kompetencia Központ által 2013 végén kiadott 20/80 (rend...
Teljes kéziratok a 20/80 sorozatba Őry Máté Alább közlöm az E-közigazgatási Szabad Szoftver Kompetencia Központ által 2013 végén kiadott 20/80 (rendszergazdai tankönyvek) című sorozathoz írt kézirataimat. A kéziratban számos szakasz részletesebben szerepel, mint az elkészült könyvekben, így akinek pont a terjedelmi okokból elhagyott részekre volna szüksége, itt megtalálhatja őket. A kézirat és a könyvek is a CC-BY-SA licenc szerint használhatóak fel. A kézirat elkészítésében nyújtott segítségét ezúton is köszönöm Guba Sándor kollégámnak. A megjelent könyvek elérhetőek a http://szabadszoftver.kormany.hu/sajat-oktatasi-anyagok/ címen: 1. Mátó Péter, Rózsár Gábor, Őry Máté, Varga Csaba Sándor, Zahemszky Gábor: 20/80 – Unix és Linux alapismeretek rendszergazdáknak, E-közigazgatási Szabad Szoftver Kompetencia Központ, 2013. 2. Mátó Péter, Rózsár Gábor, Őry Máté, Varga Csaba Sándor, Zahemszky Gábor: 20/80 – Linux rendszerek alapvető beállításai, üzemeltetése, E-közigazgatási Szabad Szoftver Kompetencia Központ, 2013. 3. Mátó Péter, Rózsár Gábor, Őry Máté, Varga Csaba Sándor, Zahemszky Gábor: 20/80 – Hálózati szolgáltatások szabad szoftverekkel, E-közigazgatási Szabad Szoftver Kompetencia Központ, 2013.
Tartalomjegyzék Alapfogalmak: parancssor, grafikus felület, különböző munkakörnyezetek (Unity, GNOME, XFCE, KDE)............................................................................................................3 A parancssor.....................................................................................................................................3 Grafikus felület................................................................................................................................4 Ablakkezelők, asztali környezetek..................................................................................................4 Grafikus belépés..............................................................................................................................8 Az operációs rendszer telepítése...........................................................................................................9 A telepítés előtt................................................................................................................................9 Telepítés optikai lemezről, USB kulcsról......................................................................................10 A telepítés menete..........................................................................................................................10 Egyes disztribúciók sajátosságai....................................................................................................11 A telepítés után...............................................................................................................................13 Tipp: telepítés hálózatról................................................................................................................13 A hardverek elérésének unixos/linuxos módja (blokkos és karakteres eszközfájlok): statikus /dev, dinamikus /dev: udev..........................................................................................................................14 Eszközfájlok típusai.......................................................................................................................14 Gyakran használt eszközfájlok......................................................................................................14 Pszeudoeszközök...........................................................................................................................16 Statikus eszközfájlok.....................................................................................................................16 Dinamikus eszközfájlok: udev.......................................................................................................16 Jogosultságok beállítása, udev-szabályok......................................................................................17 További speciális fájlrendszerek....................................................................................................18 Rendszerindítás, init, rendszerkomponensek konfigurálása (/etc).....................................................19 A bootloader...................................................................................................................................19 1
Init..................................................................................................................................................20 SysV init........................................................................................................................................21 Upstart............................................................................................................................................23 Systemd..........................................................................................................................................25 Rendszerkomponensek konfigurálása............................................................................................27 Általános célú hálózati szerver: az inetd és xinetd.............................................................................29 Inetd...............................................................................................................................................29 Xinetd.............................................................................................................................................31 Magas rendelkezésre állás alapok: hogy ne legyen egy hetes kiesés az elromlott diszk miatt..........34 Megbízhatóbb eszközök................................................................................................................34 Tartalékgép.....................................................................................................................................35 Klaszter..........................................................................................................................................35 Példa: nagy rendelkezésre állású webkiszolgáló...........................................................................36
2
Alapfogalmak: parancssor, grafikus felület, különböző munkakörnyezetek (Unity, GNOME, XFCE, KDE) A Linux rendszerekkel a legkülönbözőbb helyeken találkozhatunk: szuperszámítógépeken, nagygépeken, szervereken, hálózati- és táreszközökön, asztali gépeken, notebookokon, ipari eszközökön, mobiltelefonokon, vagy éppen a hűtőszekrényen. Számos tekintetben azonos elemekből építkeznek ezek a rendszerek, azonban a végfelhasználó mindezeket különböző felületeken éri el. Ezen felületek közül kiemelkedik a parancssori felület, ami valamilyen formában minden gépen elérhető, általában képernyőn és billentyűzettel, hálózaton, vagy soros vonalon keresztül. A fogyasztói eszközök (PC-k, táblagépek, mobiltelefonok) általában grafikus felületen érhetőek el. Ezen belül a PC-ken használt felületek alapeszköze az ablakozó rendszer, amely lehetővé teszi azt, hogy egyidejűleg több alkalmazást futtassunk, és azok között váltsunk. A táblagépek és a mobiltelefonok ezt a problémát máshogy oldják meg. Végül nem szabad megfeledkezni azokról az eszközökről sem, amelyekre közvetlenül képernyőt nem csatlakoztatunk, hanem más perifériáikkal, egyedi módon kommunikálnak a felhasználóval.
A parancssor
1. ábra. Parancssori felület Debian 7 alatt. A parancssor interfész (command-line interface, CLI) a Unix eredeti felhasználói felülete, a mai napig szinte minden rendszernek része. Ezen a felületen parancsokat gépelhetünk be, amelyeket a parancsértelmező (shell) futtat. Az alapbeállítás szerinti parancsértelmező a bash, de sokan kedvelik a csh-t, a ksh-t és a zsh-t is. 3
A parancssori felületet számos módon érhetjük el. A grafikus felület nélkül telepített Linux rendszereken általában a gép indítása után a login alkalmazás fogad minket, amely felhasználónevünket és jelszavunk megadása után elindítja a parancsértelmezőt (1. ábra). (Ne ijedjünk meg, ha a begépelt jelszavunk nem látszik, ez biztonsági okokból van így.) Ez a felület egy virtuális terminál. Az elnevezés a nagygépes Unix rendszerek korából származik, amikor a felhasználók soros vonalon, terminálokon keresztül csatlakoztak a géphez. Ez a felület ennek „virtuális” megvalósítása a gépre kötött megjelenítővel és billentyűzettel. Nem csak egy ilyen virtuális terminált érhetünk el, általában hat ilyen vonalat érhetünk el (lásd még a Rendszerindítás című fejezetet), amelyek között az Alt+sorszám billentyűkombinációkkal válthatunk. Akkor is elérhetőek a virtuális terminálok, ha a rendszerünkön grafikus felület is fut: a Ctrl+Alt+sorszám kombinációval. A parancssori felületet rugalmassága lehetővé teszi azt is, hogy számos más módon csatlakozzunk hozzá. Gyakran érjük el hálózaton, az SSH protokollon keresztül (bővebben a Távoli elérés: ssh című fejezetben). Lehetőségünk van a grafikus felületről is a gép parancssori felületét elérni, amelyhez terminálemulátorra lesz szükségünk.
Grafikus felület A grafikus felület napjainkig elterjedt megvalósítása az X11 keretrendszer. Ez egy kliens-szerver felépítésű architektúra, amelyben a szerver vezérli a megjelenítőt, míg a kliensek az egyes alkalmazások, amelyek ablakokat kívánnak megjelentetni. A legtöbb esetben a kliens és a szerver egyazon helyen fut: a képernyő arra a gépre van kötve, amely az alkalmazásokat futtatja. Ez a felépítés azonban lehetővé tesz azt, hogy különböző okokból távol futó alkalmazásokat használjunk grafikusan. Az X11 referenciaimplementációja az X.Org Server, amely egyben a legnépszerűbb is. A nyolcvanas évek óta számos örökséget magával hordó X11 szabványt számos alkalommal igyekeztek kiváltani. A jelenleg is aktív törekvések a Wayland és a Mir.
Ablakkezelők, asztali környezetek Az X11 keretrendszer szolgáltatásai korlátozottak, a megszokott felhasználói élmény eléréséhez ablakkezelőre is szükségünk van. Számos választási lehetőségünk van, azonban a legnépszerűbb ablakkezelőket számos szolgáltatást nyújtó asztali környezetek részeként érhetjük el. Az asztali környezetek közti választás ízlés kérdése, azonban a legtöbb Linux-disztribúció döntött egy-egy környezet mellett, amelyet kiemelten támogat. A közelmúltig két nagy asztali környezetet osztotta meg a Linux-felhasználókat: a GNOME és a KDE. Ezen kívül jelentős, egyszerűbb alternatíva az XFCE. Ezen a piacon jelent meg az Ubuntu új felülete, a Unity, amely nagyrészt a GNOME alkalmazásaira támaszkodik.
GNOME A GNOME az egyik legnépszerűbb asztali környezet. Számos disztribúció támogatja kiemelten különböző változatait. A GNOME 2 hosszú ideig egységes képet adott a különböző disztribúcióknak. A Red Hat Enterprise Linux és a CentOS aktuális verzióiban, valamint a Mate projektben találkozhatunk vele. 4
A GNOME 3 gyökeresen megújította a felhasználói felületet, amelyet már kevesebb disztribúció fogadott el. Az alaptelepítés része például Fedora alatt, és választható OpenSUSE alatt. A felhasználói felülete a Gnome Shell. A GNOME fontosabb alkalmazásai a Nautilus fájlböngésző, az Eye of GNOME képnézegető, a Gedit fájlszerkesztő és a Totem médialejátszó.
2. ábra. A GNOME 3 felülete, videolejátszója, fájlböngészője, képnézegetője és fájlszerkesztője.
5
Unity
3. ábra. A Unity felülete. A Unity egy alternatív felhasználói felület a GNOME 3-hoz a GNOME Shell helyett. Az Ubuntu alapértelmezett felülete, az Ubuntu projekt részeként fejlesztik.
Xfce Az Xfce egy a GNOME-nál egyszerűbb, gyorsabb és kisebb erőforrású asztali környezet. Fájlkezelője a Thunar, azonban a környezet képnézegetőt, szerkesztőt vagy médialejátszót nem tartalmaz.
6
4. ábra. Az Xfce felülete és fájlböngészője.
KDE A KDE Software Compilation az első jelentős asztali környezet. Finomhangolhatóságáról és nagy számú alkalmazásáról ismert. Fájlkezelője a Dolphin, képnézegetője a Gwenview, fájlszerkesztője a Kwrite és a Kate, médialejátszója a Dragon Player.
7
5. ábra. A KDE felülete, képnézegetője, videolejátszója, fájlszerkesztője és fájlböngészője.
Egyéb rendszerek A nagy asztali környezeteken kívül számos ablakkezelőt érhetünk még el, amelyeket a legtöbbször haladó felhasználók használnak. Kiemelhető két fő irány: a hagyományos lebegő ablakokat használó minimalista ablakkezelők (stacking window manager, például Openbox, Blackbox), valamint a csempéző ablakkezelők (tiling window manager, például awesome, i3, xmonad).
Grafikus belépés Ha számítógépünket indításától kezdve grafikusan szeretnénk használni, akkor egy bejelentkezéskezelőre (login manager) is szükségünk van. Ebből is számos alternatíva érhető el, azonban a grafikus felülettel érkező disztribúciók szintén leveszik vállunkról a választás terhét. A bejelentkezés-kezelők közül kiemelhető a GNOME-hoz kötődő GDM; a KDE részét képező KDM; valamint a GDM kiváltására készített, nála gyorsabb és egyszerűbb Lightdm.
8
Az operációs rendszer telepítése A szerverek a hozzájuk megvásárolt operációs rendszert is ritkán tartalmazzák előre telepítve, még ritkábban fordul ez elő az ingyenes Linux-disztribúciókkal. Ennek oka kézenfekvő: míg egy lakossági eszköznél a felhasználók jelentős részének megfelel az előre telepített operációs rendszer, szerver környezetben olyan döntéseket kell hoznunk a telepítést megelőzően, amelyek a telepítés menetét érdemben befolyásoljuk. Az informatikai környezetek is egyre több operációs rendszert futtatnak az évek során (először az árak csökkenése, majd a virtualizáció térnyerése miatt), így ma már nem jellemző, hogy egy rendszergazda kikerülheti az operációs rendszer telepítését. Az operációs rendszer telepítése nagy vonalakban egy a telepítést végző rendszer memóriába töltéséből, a gép hardvereinek felderítéséből, a telepítési cél kiválasztásából és előkészítéséből, a hálózat, az óra, a felhasználók beállításából, az új rendszer komponenseinek felmásolásából és a rendszerbetöltő telepítéséből áll. A folyamatot számos módon végezhetjük – ezek közül hosszú ideig az optikai lemezekről történő telepítés volt a domináns. Mivel az újabb szervereken csak elvétve találunk optikai meghajtót, ezért ezt a lehetőséget jelentős részben kiváltotta az USB kulcsokról és a hálózatról való telepítés. A Linux-telepítőknek két nagy csoportja van. Az egyik, főleg asztali rendszereknél elterjed módszer a lemezképes telepítés, amely egy telepítés nélkül is elindítható (live) rendszerből áll, amely képes önmagát fölmásolni a merevlemezre. A másik, hagyományos módszer pedig egy csupaszított Linux, amely az új rendszert a csomagkezelő segítségével telepíti. Előbbi előnye a sebessége, utóbbié pedig a szélesebb körű konfigurációs lehetőségek. Fontos megemlíteni a virtualizációt vagy sok hasonló gépet üzemeltető környezetekben gyakori klónozásos eljárást, amely egy telepített, bekonfigurált mestergép lementett lemezképéből másolással vagy valamilyen differenciális tárolási megoldással hoz létre példányokat. Végül több megoldás terjedt el lemez nélküli szerverek üzemeltetésére, amikor az egyes gépek a rendszerbetöltést hálózatról memóriába végzik, majd a szükséges tárterületet NAS vagy SAN megoldással érik el.
A telepítés előtt A rendszer telepítése előtt mindenek előtt válasszuk ki a disztribúciót, annak verzióját és változatát. Szerverek esetében ha bizonytalanok vagyunk a kérdésben, nem tévedhetünk nagyot azzal, ha az általunk vagy az intézmény által előnyben részesített disztribúció utolsó stabil, hosszú távú támogatású verzióját (Ubuntu esetén „LTS”), és annak a Server változatát telepítjük. Válasszuk ki a megfelelő architektúrát is. Modern x86 alapú rendszerek esetén gyakorlatilag nem lehet okunk a 32 bites változat telepítésére, nyugodtan válasszuk a „64 bit”, „x86-64”, „amd64” vagy „X64” jelölésű kiadást (ezek az elnevezések mind ugyanazt jelentik). Gondoljuk át, hogy milyen tárolóeszközre kívánjuk telepíteni a rendszert. Szükség esetén alakítsuk ki a hardveres RAID-konfigurációt, hozzuk létre a SAN-on a köteteket. Készítsük elő a gép hálózati elérését, szükség esetén osszunk ki neki, vagy igényeljünk IP címet, tudjuk meg az alhálózat adatait (hálózati maszk, átjáró és névkiszolgáló címe). Gondoljuk át, hogy a telepítést hányszor kell elvégezni. Néhány gépnél több esetén keressünk megoldást az automatizálásra. Ha a lemezeken már van bármilyen, korábban használt rendszer vagy adat, akkor készítsünk róla mentést – akkor is, ha nem szándékozzuk törölni a telepítés során. 9
Telepítés optikai lemezről, USB kulcsról Az ingyenes disztribúciók letöltése nem okozhat különösebb gondot, a rendszer honlapján meg fogjuk találni a megfelelő hivatkozásokat. Amennyiben nem szabadon elérhető rendszert szerzünk be, kövessük a forgalmazó tájékoztatását. A legtöbb esetben CD- vagy DVD-képet tölthetünk le, amelyet a .iso kiterjesztésről ismerünk fel. Amennyiben optikai lemezről kívánjuk elvégezni a telepítést, nincs más dolgunk, mint a lemezt egy megfelelő méretű üres adathordozóra kiírni. Ezt a legtöbb Linux rendszeren a fájlra jobb gombbal kattintva és a „lemezre írás” opciót választva, Windows alatt például az ingyenesen elérhető Infra Recorder nevű alkalmazással tehetjük meg. Amennyiben USB kulcsról telepítenénk, a lemez kiírásához speciális szoftverre lesz szükségünk. Linux alatt ez az usb-creator, míg Windows alatt a UNetbootin nevű alkalmazással a legegyszerűbb. A telepítés indításához mindkét esetben helyezzük be a gépbe a telepítő médiát, és indítsuk újra. A gép kézikönyvében szereplő módon válasszuk ki a rendszerindításra szolgáló eszköznek (boot device) az optikai meghajtót vagy az USB kulcsot. Számos esetben ezt az F12 billentyű megnyomásával tehetjük meg.
A telepítés menete A telepítő betöltése, alapvető konfiguráció A telepítő elindulásakor általában elsőként ki kell választanunk egy menüben, hogy telepíteni (install) szeretnénk a rendszert. Ne ijedjünk meg, ha ezután hosszabb ideig várnunk kell, ilyenkor töltődik be a telepítéshez szükséges alaprendszer. A telepítő betöltése után egy varázsló jellegű felület fogad minket, amely az első lépésként kiválasztott nyelven végigvezet minket a telepítés menetén. A telepítés során számos kérdésre kell válaszolnunk. Az egyik első kérdéscsoport a helyi beállításokra vonatkozik: ki kell választanunk a rendszer alapértelmezett nyelvét, a billentyűkiosztást, valamint az országot vagy az időzónát. Egyes rendszerek megkérdezik, hogy helyi idő vagy UTC szerint jár a gépünk hardveres órája – csak akkor válasszuk a helyi időt, ha az adott gépen Windowst is futtatni szeretnénk. Az órát célszerű pontosan beállítani, és az automatikus időszinkronizációt bekapcsolni (lásd az Egy szerver alapvető beállításai című fejezetet).
Felhasználói fiókok A gépünk felhasználóival kapcsolatban is válaszolnunk kell néhány kérdésre. A rendszerek egy része létrehoz egy általános felhasználót, akinek joga van adminisztratív feladatok végrehajtására. Más rendszerek (Debian, CentOS) egy külön, root nevű felhasználónak állítják be az általunk megadott jelszót. Az általános célú felhasználónak mindkét esetben célszerű, hogy a saját nevünket adjuk – az esetleges további felhasználókat majd később hozzáadhatjuk (lásd a Felhasználók és csoportok című fejezetet.)
Hálózati beállítások A telepítők elvégzik a hálózat alapvető beállításait is. Több hálózati interfész esetén ki kell választanunk azt, amelyen az internetet érjük el – ezt jobb megoldás híján a kártya típusa és MAC címe alapján kell megtennünk. Amennyiben a hálózaton automatikus konfigurálás (DHCP) 10
működik, azt a telepítő automatikusan fölismeri és használja. Ha fix beállításokat szeretnénk megadni, akkor azt a kérdésekre válaszolva tehetjük meg. Ebben az esetben a gép IP címére, az alapértelmezett átjáróra és az alhálózati maszkra, valamint a névkiszolgáló címére lesz szükségünk (bővebb útmutatás az Alap hálózati infrastruktúra című fejezetben). Egyes rendszerek megkérdezik, hogy a rendszercsomagokat melyik kiszolgálóról szeretnénk letölteni.
Lemezek előkészítése A telepítés legnagyobb figyelmet igénylő pontja a lemezek beállítása. Ilyenkor kell beállítanunk a redundáns lemeztömböket (RAID), valamint a logikai kötetkezelőt (LVM). Amennyiben nincs, vagy nem használjuk egy szerver hardveres RAID szolgáltatását, akkor célszerű valamilyen szintű szoftveres RAID-et beállítanunk. Ilyenkor a választásunk a rendelkezésre álló lemezeszközök száma, a szükséges kapacitás és az elvárt teljesítmény alapján kell megszülessen (részletes ismertető és tanácsok a Diszkek kezelése című fejezetben). A RAID tömbökre általában a logikai kötetkezelőt is érdemes beállítani, hiszen minimális teljesítményveszteséggel dinamikusan átméretezhető és létrehozható köteteket, valamint a pillanatfelvétel lehetőségét nyerjük vele. A RAID beállításában rendszerint párbeszédes felület segít minket, ahol megadhatjuk a kívánt RAID-szintet, a használandó A legtöbb esetben a telepítő fölajánl néhány szövegesen körülírt beállítást, valamint az egyéni választás lehetőségét. Mindenek előtt döntsük el, hogy szükségünk van-e szoftveres RAID-re vagy LVM-re, valamint hogy van-e speciális igényünk a kötetekkel kapcsolatban (részletes ismertető és tanácsok a Diszkek kezelése című fejezetben). RAID és LVM esetén előfordulhat, hogy a /boot/ könyvtárban lévő, a rendszer indításához szükséges fájlokat nem tudja elérni a rendszerbetöltő. Ebben az esetben szükség lehet a könyvtár külön, a tömbön kívüli köteten való elhelyezésére.
Csomagok, szerepkörök A rendszerek egy része a telepítendő csomagok közti választást is lehetővé teszi – erre természetesen elsősorban a csomagalapú telepítőknél van lehetőség. A csomagok rendszerint kategóriákra, feladatokra vagy szerepkörökre vannak szedve, így olyan lehetőségek között választhatunk, mint a „KDE asztali környezet” vagy a „LAMP szerver”. (Debian és Ubuntu alatt a tasksel nevű eszközzel, CentOS alatt a yum grouplist/groupinstall, míg OpenSUSE alatt a yast segítségével ezek a telepítés után is kiválaszthatóak.)
Bootloader A folyamat végén kérdeznek rá a telepítők a rendszerbetöltő helyére.
Egyes disztribúciók sajátosságai Debian A Debian telepítője számos változatban érhető el. A klasszikus változat az összes csomagot tartalmazó optikailemez-gyűjtemény, azonban mivel a csomagokat manapság egyszerűbb és gyorsabb internetről telepíteni, vagy csak az első, a telepítőt tartalmazó lemezt, vagy egy speciális változatot, például az XFCE grafikus környezetet tartalmazó médiát érdemes letölteni. 11
A telepítő egy karaktergrafikus, párbeszédes jellegű felület. Figyeljük a megjelenő utasításokat, amik leírják, hogy hogyan tudunk navigálni: a választási lehetőségek között tabulátorral és a nyílbillentyűkkel, egyes helyekre belépni vagy a választást elfogadni enterrel, onnan kilépni az escape-pel lehet. Választási lehetőségeket szóközzel jelölhetünk ki. A telepítőnek elérhető grafikus változata is, amely egyebekben megegyezik a karaktergrafikus változattal. A Debian kiadási ciklusa hagyományosan az „amikor kész van” elv szerinti, viszont új kiadáskor az előző támogatása egy év után megszűnik. A jövőben kétévente lesz kiadás, tehát egy telepített rendszert kedvező esetben 3 évig használhatunk verziófrissítés nélkül – kedvezőtlen esetben csak bő 1 évig. Mindig az utolsó stabil verziót használjuk, ha nem kísérletezni szeretnénk.
Ubuntu Az Ubuntunak két telepítője van. A desktop rendszerkhez ajánlott live telepítő egy teljes értékű, optikai lemezről vagy USB kulcsról futtatható rendszer, amely tartalmaz egy grafikus telepítő alkalmazást is, amely kevés beállítást követően felmásolja a lemezképet a lemezeszközökre. A telepítés nem igényel különösebb magyarázatot. A legújabb verziók felajánlják a logikai kötetkezelőre való telepítést is, azonban a szoftveres RAID-et nem – így ha ezekre van szükségünk, nem célszerű választás. A másik, „alternate” vagy „server” telepítő a karaktergrafikus Debian Installert használja különösebb módosítások nélkül. Ezzel a telepítővel van lehetőségünk alaposabb beállításokra, így különlegesebb lemezkonfigurációra való telepítésre vagy a grafikus rendszer mellőzésére. A teljes desktop rendszer telepítése esetén ez a módszer lassabb. Az egyetlen jelentős eltérés a Debiantól az, hogy Ubuntu alatt nincs a root felhasználónak jelszava, hanem a telepítés során létrehozott felhasználónak van jogosultsága sudo segítségével root-ként parancsokat végrehajtani. Az Ubuntu verziószámozása a kiadási időpontot mutatja, a 12.04 verzió például 2012. áprilisában készült el. Az Ubuntu kiadási ciklusa két elemből áll. Kétévente készül LTS (long term support, hosszú távú támogatású) verzió, míg félévente van normál kiadás. Az LTS verziók kiadásuktól 5 évig, a normál verziók 9 hónapig vannak támogatva. Az LTS verziókat így 3–5 évig használhatjuk verziófrissítés nélkül. Mindig az utolsó LTS verziót használjuk, ha nem kísérletezni szeretnénk.
CentOS A CentOS telepítője egy minimális grafikus rendszer, amely csomag alapon telepíti a CentOS-t a lemezekre. Vállalati disztribúcióként kifejezetten támogatja a hálózati tárolóra való telepítést, valamint a logikai kötetkezelő használata is alapértelmezett. Mivel a CentOS-ben még Grub Legacy található, figyeljünk arra, hogy külön /boot/ partíciót hozzunk létre szoftveres RAID vagy LVM telepítése esetén. A RHEL kiadási modelljében (amelyet a CentOS is követ) főverziókat 10 évig látják el biztonsági frissítésekkel, és új főverziót 3 évente adnak ki. Így 7–10 évig használhatjuk verziófrissítés nélkül a rendszert.
OpenSUSE A OpenSUSE az Ubuntuhoz hasonlóan kétféle módon telepíthető optikai lemezről vagy USB kulcsról. Az ajánlott telepítő egy teljes DVD-n tartalmazza a legtöbb csomagot, beleértve a teljes 12
KDE és Gnome asztali környezetet. Ezt a telepítőt elindítva egy minimális grafikus rendszert kapunk, amely csomag alapon telepíti a rendszert a lemezekre. A telepítés során számos tekintetben konfigurálhatjuk a rendszert, de a legtöbb helyen jól használható alapbeállításokkal találkozunk. A másik módszer a live rendszer, amely egy teljes értékű Gnome vagy a KDE asztali környezetet tud elindítani optikai lemezről vagy USB kulcsról. A rendszer elindítása után lehetőségünk van a telepítő indítására is, amely kevesebb beállítási lehetőséget ad, de lemezkép másolásával gyorsan települ. Az OpenSUSE kiadások 9 havonta készülnek, és 18 hónapig érhetőek el hozzájuk biztonsági frissítések. Így egy verziót 9–18 hónapig használhatunk verziófrissítés nélkül. Egy közösségi projekt, az Evergreen egyes verziókat további 18 hónapig támogat.
A telepítés után A telepítés után már a lemezeszközökről indíthatjuk a gépet. Első feladataink között lehet a hálózat beállítása, valamint a távoli elérés (SSH) engedélyezése. Érdemes idejében bekonfigurálni egy egyszerű tűzfalat is (a CentOS és az OpenSUSE a telepítés során ezt elvégzi helyettünk, Debian és Ubuntu alatt sok esetben elegendő lehet az ufw engedélyezése). Telepítsük az adott környezetben rendszeresített eszközöket (például a monitorozáshoz szükséges ágenseket), és állítsuk vegyük fel a szükséges felhasználókat vagy állítsuk be a címtárat. Ellenőrizzük az automatikus csomagfrissítés működőképességét is. Mindezek után érdemes a gép tényleges funkciójához szükséges szoftvereket telepíteni és beállítani.
Tipp: telepítés hálózatról Ha nem szeretnénk optikai lemezekkel vagy USB kulcsokkal bajlódni, célszerű lehet a hálózati telepítés is. Ehhez mindössze internetelérésre, egy megfelelően beállított DHCP kiszolgálóra, valamint egy TFTP kiszolgálóra van szükségünk. Mindezeket a funkciókat biztosítja a dnsmasq nevű pehelysúlyú DHCP és DNS kiszolgáló, amely a legtöbb rendszer alaptelepítésének része. A legegyszerűbb hálózati elrendezésben egy külön hálózati szegmensben indítjuk el a szükséges szolgáltatásokat, így nem okoz gondot az, ha például több DHCP kiszolgáló futna így. Ehhez használjunk egy Ubuntu Desktopot futtató gépet, amelynek van egy szabad hálózati interfésze (például egy az internetet vezeték nélkül elérő noteszgép). Töltsük le a kiválasztott disztribúció hálózati telepítéshez előkészített telepítőcsomagját, amelyet bontsunk ki egy mindenki számára elérhető jogosultságokkal rendelkező könyvtárba. Ezután kössük össze a két gépet hálózati kábellel, és állítsuk be az internetkapcsolat megosztását. Lőjük ki az esetleg már futó dnsmasq-t, majd indítsunk el egy speciálisan konfigurált példányát. Ezek után már csak a telepítendő gépet kell elindítanunk úgy, hogy a hálózatról való rendszerbetöltést engedélyezzük. A fent leírt esetben, az Ubuntu 12.04 rendszer 32 bites változatával a teljes folyamat parancsokban: # mkdir /tmp/tftpboot; cd /tmp/tftpboot # wget http://archive.ubuntu.com/ubuntu/dists/precise/main/installeri386/current/images/netboot/netboot.tar.gz -O - | tar xvzf # chown -R nobody: ./ # ifconfig eth0 192.168.77.1 # iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE # echo 1 >/proc/sys/net/ipv4/ip_forward # cat >cfg <<END dhcp-range=192.168.77.20,192.168.77.30,12h
Nagyobb körültekintéssel kialakítva az éles hálózatban is futtathatunk ilyen szolgáltatást, azonban ezt is célszerűbb egy erre a célra kialakított hálózati szegmensben megtenni.
14
A hardverek elérésének unixos/linuxos módja (blokkos és karakteres eszközfájlok): statikus /dev, dinamikus /dev: udev Az operációs rendszer feladata a hardverelemek és a felhasználó közötti kapcsolat biztosítása. A UNIX rendszer – és így a Linux is – ezt a legtöbb eszközzel eszközfájlokon keresztül oldja meg. Ezzel a megoldással a különböző eszközök kezelése az általános fájlinterfészen keresztül történhet, úgy, hogy a programnak az adott eszköz sajátosságait nem kell ismernie. Így válik lehetővé például, hogy egy mágnesszalagok kezelésére írt programmal SSH-kapcsolaton át is lehet mentést készíteni, vagy egy lemezek másolására valóval hangfelvételt készíteni és visszajátszani. Az eszközfájl egy speciális fájl, amelynek a műveleteit (mint az írás vagy az olvasás) a rendszermag nem a fájlrendszerrel valósítja meg, hanem más módon, tipikusan egy periféria működtetésével. Így érhetik el a felhasználói térben futó programok egy általános interfészen keresztül a lemezmeghajtókat, a terminált (billentyűzetet, egereket), a soros vonalakat, a hangkártyát, vagy éppen a kernelmemóriát.
Eszközfájlok típusai Az eszközfájloknak két típusa van: a karakteres- és a blokkeszközök. A karakteres eszközökre az írás-olvasás byteonként, pufferelés nélkül történik, és általában nincs lehetőség címzésre, ugrásra (ilyen például egy soros vonal – amit kiírtunk vagy beolvastunk, az „elveszik”). A blokkeszközöket pufferelve, blokkonként (eszköztől függően néhány kilobyte-os egységenként) kezeli a rendszer, és címezhetőek (ilyen például egy lemezmeghajtó). Az karakteres- (c) és blokkeszközfájlok (b) ugyanúgy útvonal alapján érhetőek el, mint a többi fájltípus – a közönséges fájlok (-), a könyvtárak (d), a szimbolikus linkek (l), vagy éppen a csővezeték (pipe, p) vagy a socket (s). A két eszközfájltípust legegyszerűbben az ls -l paranccsal különböztethetjük meg – a kimenet első oszlopa a fájl típusát mutatja a felsorolás szerinti jelölésekkel: $ ls -l /dev/sda /dev/ttyS0 brw-rw---- 1 root disk 8, 0 dec crw-rw---- 1 root dialout 4, 64 dec
2 17:20 /dev/sda 2 17:20 /dev/ttyS0
Észrevehetjük a fenti példában is, hogy a listázáskor az ötödik mezőben, az eszközfájlokra nem értelmezhető fájlméret helyén két, vesszővel elválasztott szám szerepel. Ezek a „major”- és „minor”-számok, amelyek a kernel felé az elérni kívánt eszközt azonosítják.
Gyakran használt eszközfájlok Fizikai lemezek Leggyakrabban a lemezekkel kapcsolatban találkozunk az eszközfájlokkal a gyakorlatban. Helyes beazonosításuk létszükséglet, mivel jelentékeny adatvesztést tud okozni egy tévedés: gondoljunk csak arra, ha a múlt heti biztonsági mentést írjuk az éles rendszerre ahelyett, hogy új mentést 15
készítenénk. A lemezfájlok a legtöbb esetben a /dev/sda-val kezdve, az ábécé betűivel azonosítva találhatóak meg: az első eszköz az sda, a második az sdb stb. Ezek a blokkeszközök az egész lemezeszközre vonatkoznak, beleértve például a partíciós táblát is. Az sd előtag a SCSI Disk-et jelzi, mivel a modern Linuxban a SATA, SAS és ATA eszközök is ezt a réteget használják. Az újabb RAID vezérlők által biztosított RAID tömbök is ilyen eszközként látszanak. Amennyiben a lemezen partíciók is vannak, azok külön is elérhetőek sorszámozva: például az sda lemez első partíciója /dev/sda1 néven. DOS partíciós tábla esetén a négy elsődleges partíció helye után, 5-től számozva szerepelnek a logikai partíciók. A felismert partíciókat a cat /proc/partitions paranccsal is listázhatjuk. Régebbi rendszermagokkal, IDE vezérlők esetén még egyértelműen meg lehetett találni egy eszközt (hda: primary master, hdb: primary slave, hdc: secondary master stb.). A fejlettebb interfészeken erre már nincs lehetőség. Erre a problémára megoldás az Udev által biztosított /dev/disk/ könyvtár, amely különböző szempontok alapján rendezve ad szimbolikus linkeken át egyértelműbben azonosítható elérési utakat. A /dev/disk/by-id/ könyvtárban hardveres azonosítók és címkék alapján, a /dev/disk/by-path/-ban a legrövidebb elérési útvonal alapján, míg a /dev/disk/byuuid/ könyvtárban az egyes fájlrendszerek UUID-ja (egyedi azonosítója) alapján érhetjük el az eszközfájlokat.
További blokkeszközök A fizikai eszközökön kívül további táreszközöket is érhetünk el eszközfájlokon keresztül. A logikai kötetkezelő (LVM) logikai kötetei (lv, logical volume) /dev/dm-* néven, sorszámozva találhatóak meg. Mivel ezek értelmezése is nehéz, ezért a /dev/mapper/ könyvtárban könnyebben értelmezhető szimbolikus linkeket találunk, amelyek /dev/mapper/kötetcsoport-logikaikötet néven mutatnak a megfelelő eszközfájlra. Hasonló linkeket kötetcsoportonként csoportosítva is elérhetjük, /dev/kötetcsoport/logikaikötet néven. A szoftveres RAID tömböket /dev/md0-val kezdve, sorszámozva érhetjük el. Beazonosításukban az mdadm eszköz segíthet. Fájlok fájlrendszerként vagy lemezként való csatolására is lehetőség van Linux alatt, azonban ehhez virtuális lemezeszközre van szükség. Ezt a loop kernelmodul végzi, amely betöltésekor fix számú eszközfájlt hoz létre. Ezután a losetup eszközzel állíthatjuk be a /dev/loop* néven megtalálható eszközök mögötti fájlt. Fájlban tárol fájlrendszerek csatolására (és a loop eszköz beállítására) a mount is képes: a mount -oloop ~/fs.img /mnt/ paranccsal a /mnt/-be csatoljuk a ~/fs.img fájl tartalmát.
Karaktereszközök A leggyakrabban használt karakteres eszközök a különböző terminálok, soros vonalak. A nevükben rendszerint találkozunk a „tty”-vel, amely a teletype (géptávíró) rövidítése, és a terminálként való használatukra utal. A virtuális terminálok általában /dev/tty[1-6] néven találhatóak. Az első soros vonal (DOS-os terminológiában COM1) rendszerint a /dev/ttyS0, a második a ttyS1 stb. USB-soros átalakítók az eszköz típusától függően, például /dev/ttyUSB0 néven érhetőek el. A /dev/tty egy olyan speciális eszköz, amely mindig az adott folyamat vezérlő termináljára mutat, így akkor is tudunk például egy shell szkriptből a konzolra írni vagy onnan beolvasni, ha a ki/bemenetek át vannak irányítva (echo Jelszó: >/dev/tty && read passwd
paraméterei, majd például cat-tal írni és olvasni is lehet rá), terminálprogrammal a legkényelmesebb. Sok rendszeren alapból elérhető a GNU screen, amely egyebek mellett soros terminálként is működik. Például egy ttyS0-ra kötött, 38400 baudon működő switch-re beléphetünk a screen /dev/ttyS0 38400 paranccsal (ctrl+A, ctrl+K-val léphetünk ki).
Pszeudoeszközök A rendszermag számos olyan szolgáltatást is nyújt, amelyeket ugyan eszközfájlokon keresztül lehet elérni, azonban mögöttük nem egy hardvereszköz áll. Gyakran felmerülő probléma az, hogy egy alkalmazás írni akar egy fájlba, azonban erre nincs szükségünk. Ilyenkor használjuk a nulleszközt, amely egy végtelen nyelő (sink). A szabványos helye a /dev/null. Az ebbe a fájlba írt adatot a rendszer eldobja. Olvasáskor egy nulla byte-os, üres fájlként viselkedik. Például ha egy HTTP lekérést kell csinálnunk, de az eredményére nincs szükségünk, a wget -O /dev/null http://drupalsite.tld/cron.php parancs a nulleszközbe menti a letöltött fájlt. Hasonló eszköz a /dev/zero, amely íráskor hasonlóan működik a nullhoz, azonban olvasáskor nem üres fájlként, hanem végtelen forrásként viselkedik, mint egy végtelen hosszú, nullákból álló bináris fájl. Például a head -c 1024 fájlom parancs beolvas 1024 darab nulla-byteot a zero eszközből és a fájlom nevű fájlba írja. A /dev/random és a /dev/urandom is végtelen forrásként működik, azonban nem nullákat, hanem véletlenszerű byteoket lehet belőlük olvasni. A head -c 1024 fájlom parancs így egy 1024 byteos, véletlenszerű tartalmú fájlt hoz létre. A két eszköz között az a különség, hogy az urandom csak pszeudovéletlen generátor, így sokkal gyorsabban olvasható, mint a valódi véletlen számokat biztosító random eszköz. Vegyük azonban figyelembe, hogy a rendszer entrópiájától függően sokáig tarthat akár kevés byte kiolvasása is a random eszközből. Ha például a /dev/sdx nevű lemezeszköz teljes tartalmát szeretnénk megsemmisíteni, akkor jó választás lehet a cat /dev/urandom >/dev/sdx parancs.
Statikus eszközfájlok Az eszközfájlokat hagyományosan általános célú fájlrendszereken hozhatjuk létre, helyük a /dev/ könyvtár. Ezeket a fájlokat csak ritkán kell magunknak létrehoznunk, a telepítő elvégzi ezt a feladatot. Ha esetleg mégis hiányzik egy eszközfájl, és ismerjük a típusát, valamint major és minor számait (ezeket a rendszermag dokumentációjában, a devices.txt fájlban találjuk) akkor azt az mknod paranccsal hozhatjuk létre. Például az esetleg hiányzó /dev/null eszközt (mely egy karakteres eszköz (c), major száma 1 és minor száma 3) a root felhasználó az mknod -m 666 /dev/null c 1 3 paranccsal hozhatja létre (a 666 az eszközfájl védelmi kódja: mindenki írhatja és olvashatja). A hiányzó eszközfájlok létrehozását a statikus eszközfájlokat használó rendszereken a kívánt könyvtárban kiadott MAKEDEV parancs végzi el automatikusan. A statikus eszközfájlok karbantartása több okból is nehézkes. A gépen rendszeresített összes eszközfájlnak léteznie kell akkor is, ha az eszköz éppen nincs csatlakoztatva – ellenkező esetben a root felhasználónak kell az eszközfájlokat létrehoznia és törölnie. A disztribúciók által szállított „mindent bele” moduláris kernelek esetében már az adott fájlnevekhez tartozó eszköz sem feltétlenül egyértelmű. Azonban a kis erőforrással rendelkező és ritkán változó hardverkonfigurációjú beágyazott rendszerekben, valamint más UNIX rendszerekben még előfordul, hogy a telepítéskor létrehozott, statikus eszközfájlokat használják.
17
Dinamikus eszközfájlok: udev Az eszközfájlok létrehozásának és karbantartásának elkerülésére készült a devfs fájlrendszer, amely az aktuális disztribúciókban már ritkán fordul elő. Ez egy virtuális fájlrendszer, amelyben a kernel automatikusan hozza létre az eszközfájlokat. Számos hiányossága van: az eszközök állandó elnevezéseit, vagy a jogosultságok konfigurálásának lehetőségét sem biztosítja megfelelően. A feladat megoldásának korszerű, általánosan elterjedt módja az udev használata. Ez egy olyan felhasználói térben futó szolgáltatás, amely a kerneltől értesítést kap az eszközök csatlakoztatásáról, és a konfigurációjában megadott szabályok alapján hozza létre, állítja be és törli az eszközfájlokat, valamint értesíti a felhasználói folyamatokat (például az asztali környezetet) erről. Az udev által kezelt eszközfájlokat általában egy memóriában tárolt fájlrendszerre írjuk, mivel az operációs rendszer minden indítása után létrejönnek. A legkézenfekvőbb ilyen fájlrendszer a tmpfs, amelyet egyszerűen csatolhat a root felhasználó a mount -t tmpfs none /csatolási/pont paranccsal más célra is. Mivel az elmúlt években sok disztribúció céljai között szerepelt a rendszerbetöltés gyorsítása, amit az udev szolgáltatás korai elindítása hátráltat, bekerült a Linux rendszermagba egy olyan, devtmpfs nevű öszvér-fájlrendszer, amely a devfs-hez hasonló megoldásaival automatikusan hozza létre az eszközfájlokat, de a jogosultságok beállításáról, a szimbolikus linkek létrehozásáról és az értesítésekről nem gondoskodik. Ezt a fájlrendszert az init folyamat csatolja, és csak később indul el az udev szolgáltatás. Egyes egyfelhasználós beágyazott rendszerek önmagában, udev daemon nélkül is használják ezt a fájlrendszert.
Jogosultságok beállítása, udev-szabályok Az eszközfájloknál gyakori probléma a megfelelő jogosultságok beállítása. Ugyanaz a jogosultsági rendszer érvényes az eszközfájlokra, mint más fájltípusokra (lásd a Jogosultságok, azok használata című fejezetet). Statikus /dev/ esetén nem okoz gondot a chown és chmod parancsokkal a szükséges jogosultságok beállítása, azonban a dinamikus udev esetén ez csak ideiglenes megoldás lehet. Van ellenben egy kényelmes lehetőség az egyes eszközök jogosultságainak és tulajdonosának, csoportjának megadására. Az udevd, az eseményeket kezelő daemon az egyes események kezelésekor a konfigurált szabályok alapján dönti el a teendőket. Bár a beépített szabályok az esetek többségében elegendőek, a jogosultságok szabályozását bővítésükkel tudjuk a legegyszerűbben megtenni. A szabályok felépítése az udev(7) kézikönyvoldalon van részletesen leírva (man 7 udev). A szabályok egy sorosak, és vesszővel elválasztott kulcsérték párokból állnak. Az operátor lehet a szokásos összehasonlítások egyike, mint az == az egyenlőség vizsgálatára, vagy a ! = a tagadása, valamint az = értékadás, vagy a += hozzáfűzés. Így ezek egyrészt az érintett eszköz beazonosítását biztosítják, másrészt a teendőket határozzák meg. Az eseményt azonosíthatjuk a típusa alapján az ACTION kulccsal (általában a betöltése az érdekes, amelyet az ACTION=="add" kifejezéssel köthetünk ki), a KERNEL kulccsal a neve alapján, vagy a SUBSYSTEM kulccsal az őt kezelő alrendszert, majd ezen belül ATTR{név} kulcsokkal az adott eszközt. Az egyes eszközök illeszthető azonosítóinak meghatározásában sokat segít az udevadm info --name=/dev/eszköz –attribute-walk parancs, amely kiírja az eszköz attribútumait. Az udevadm monitor paranccsal pedig az eseményeket figyelhetjük valós időben. Hasznos segítség lehet a gyári konfiguráció is, amely a /lib/udev/rules.d/ könyvtárban található. A leggyakrabban használt beállítások az OWNER, a GROUP és a MODE, amelyekkel rendre a tulajt, a csoportot és a védelmi kódot állíthatjuk be. Ezen kívül a SYMLINK kulcshoz adhatunk 18
hozzá a += operátorral további szimbolikus linkeket. Ha például a /dev/ttyS0 eszköz gyári védelmi kódját szeretnénk 666-ra emelni és a users csoportnak adni, akkor a KERNEL=="ttyS0", ACTION=="add", GROUP="users", MODE="0666" szabályt használhatjuk. A szabályokat a /etc/udev/rules.d/ könyvtárban lévő szövegfájlokban adhatjuk meg, amelyeket az udev betűrendben tölt be. A fenti szabályunkat így például a /etc/udev/rules.d/99ttyS.rules fájlba másolhatjuk.
További speciális fájlrendszerek Az eszközfájlokat tartalmazó /dev/ könyvtáron kívül érdemes még megemlíteni két speciális fájlrendszert. Az egyik, régebb óta létező a procfs, amely rendszerint a /proc/ könyvtárba van csatolva. Ebben a fájlrendszerben a gépen futó folyamatok képviselnek egy-egy folyamatazonosítójukkal (pid-jükkel) elnevezett könyvtárat. A könyvtárakban számos adatot találunk a futó folyamatokról. Például az 1-es pid-ű, init folyamat elindítására használt parancssort a /proc/1/cmdline fájlban találjuk, az argumentumokat \0 (nul) karakterekkel elválasztva. Ezt például a tr '\0' ' '
19
Rendszerindítás, init, rendszerkomponensek konfigurálása (/etc) A számítógépes rendszerek egyik fontos folyamata az elindításuk. Bár ideális esetben erre egy szerver teljes életciklusa során csak egyszer lenne szükség, a valóságban ez ritka – a legnagyobb gondosság ellenére is előfordulhat hardverhiba, áramszünet, újraindítást igénylő szoftvermódosítás. Emiatt is fontos, hogy a rendszer indítása teljesen automatikus, kipróbált és bármikor megismételhető legyen – ne egy áramszünet után derüljön ki, hogy nem indul el minden szolgáltatás, vagy nem töltődik be minden beállítás. Ha még sincs minden rendben, akkor jobb esetben csak nem működik valami, de rosszabb esetben biztonsági hiányosság keletkezik a rendszerben. A rendszerindításra úgy is tekinthetünk, hogy egy ismert, a gép bekapcsolását követő, kezdőállapotból jól definiált lépésekkel jut el a kívánt üzemi állapotba. Napjaink irodai- és kiszolgálógépei bekapcsoláskor alaphelyzetbe állítják a komponenseiket, majd végrehajtják a rendszer indítását végző szoftvert, a BIOS-t vagy az UEFI-t, amelyek elvégzik a szükséges hardverteszteket, felderítik az operációs rendszer betöltésére alkalmas forrásokat, majd a beállítások alapján megkezdik a rendszerbetöltést a megfelelő forrásból (például merevlemezről, cserélhető médiáról vagy a hálózatról).
A bootloader Az operációs rendszereket általában merevlemezre (vagy újabban szilárdtestmeghajtóra) telepítik. A BIOS-t használó rendszerek esetében a rendszerbetöltésre kiválasztott lemez elején (master boot record, MBR) szerepel egy rendszerindító, amely képes megkezdeni az operációs rendszer betöltését. Ez a rendszerbetöltő (bootloader) modern Linux rendszerek esetében általában a GNU GRUB 2, amely számos összetett tárolási megoldással együttműködve tudja betölteni a megfelelő rendszermagot, valamint lehetővé tenni a rendszerek közti választást. Régebbi rendszerek a jelentősen eltérő működésű GRUB Legacy (GRUB 1) vagy a LILO bootloadereket használják. A BIOS-t kiváltó, nála korszerűbb és gyorsabb UEFI rendszer kezeli a GPT partíciós táblát, amely kiküszöböli az évtizedes, DOS típusú partíciós táblák megkötéseit. Az MBR-re sincs szükség, ugyanis az UEFI képes a partíciós táblát értelmezni és egy boot partícióról elindítani a rendszerbetöltőt. A GRUB 2 be tudja tölteni az operációs rendszert különböző RAID-tömbökről és LVM-ről is, valamint számos típusú fájlrendszerről. Beállítása rendszerint a telepítő feladata. Konfigurációját a /etc/default/grub fájlban szereplő változók és a /etc/grub.d/ könyvtárban szereplő héjprogramok alkotják, amelyeket a update-grub parancs futtat, majd kimenetüket a /boot/grub/grub.cfg fájlba fűzi össze (amely kimenet szintén egy héjprogramot ad, azonban ezt a GRUB 2 futtatja a rendszer betöltésekor). A GRUB 2 telepítésére a grub-install parancs szolgál, melynek argumentumaként kell megadnunk a telepítésre kijelölt lemezeszközt (például grubinstall /dev/sda).
20
Amennyiben a rendszerbetöltő nem képes olvasni a rendszer gyökérfájlrendszerét, akkor szükség lehet arra is, hogy a kernelt és a bootloader moduljait tartalmazó /boot/ könyvtár egy külön, egyszerűbben olvasható – például nem titkosított, a lemez elején lévő – köteten legyen. Ha a kernel betöltését a bootloader elvégezte, megkezdődhet az operációs rendszer indításának érdemi része, az init folyamat. Ez sem lehetséges azonban azonnal minden esetben. Ennek fő oka az, hogy a folyamathoz szükséges az, hogy a gyökérfájlrendszer elérhető legyen a kernel számára. A disztribúciók azonban olyan kerneleket szállítanak, amelyek az összes támogatott hardveren működnek. A mindezekhez szükséges meghajtók memóriában tartása, a kernelbe történő statikus „beforgatása” azonban nem célszerű, ezért dinamikusan betölthető kernelmodulokkal oldják meg a széles hardverpaletta támogatását. Ezen modulokat viszont valahonnan be kell tölteni, amire az initrd (init ramdisk), egy az indítás idejére használt, a memóriába tölthető lemezkép a megoldás. Ez a lemezkép tartalmazza a szükséges modulokat, valamint egy héjprogramot, amely elvégzi a végleges gyökérfájlrendszer csatolását és az ehhez szükséges feladatokat. Egyéni initramfs képek létrehozására szolgál a széles körben használt dracut keretrendszer. Hálózatról történő rendszerbetöltésnél is ez a megoldás, azonban ilyenkor az initrd feladata a hálózat beállítása és a hálózati fájlrendszer csatolása is. A disztribúciók telepítői is gyakran az initrdben kerülnek megvalósításra. A GRUB 2 konfigurációjához általában elegendő a /etc/default/grub fájl módosítása, mivel a telepített kernelekhez és a telepítéskor felfedezett más operációs rendszerekhez automatikusan létrejönnek a bejegyzések. A GRUB_DEFAULT opcióban az alapértelmezett bejegyzés sorszámát vagy nevét adhatjuk meg; míg a GRUB_CMDLINE_LINUX opcióval kiegészíthetjük a kernelnek átadott paramétereket (például ha gondjaink vannak a konzol megjelenítésével, itt adhatjuk meg a nomodeset opciót, amely letiltja a felbontás automatikus állítását). A konfiguráció módosítása után adjuk ki az update-grub parancsot. Az alapértelmezettől eltérő rendszer indításához a rendszer indítása közben megjelenő menüből választhatunk a billentyűzettel. A GRUB_TIMEOUT=0 beállítás esetén azonban ez a menü nem jelenik meg, csak akkor, ha a GRUB 2 betöltése pillanatában a shift billentyű le volt nyomva. Amennyiben a megjelenő menüben nem találunk megfelelő bejegyzést, akkor a képernyőn szereplő útmutatás alapján módosíthatjuk is a meglévőket. Például a linux kezdetű sor végére init=/bin/bash-t írva a rendszerszolgáltatások elindítása helyett jelszó megadása nélkül egy parancsértelmezőt indíthatunk.
Init Miután betöltődött a kernel és elvégezte a folyamatok indításához szükséges lépéseket, elindul az init folyamat, amely a felhasználói térben (userspace) futó szolgáltatások indítását és megállítását hajtja végre – ebből adódóan minden folyamat az init leszármazottja. Az init rendszernek egészen a közelmúltig a SysV1 megvalósítása és a vele kompatibilis megoldások volt a jellemző Linux alatt, azonban főleg a teljesítményével kapcsolatos kifogások miatt két új megoldás, az Upstart és a Systemd terjedt el. A rendszerek közötti érdemi választás lehetősége általában a disztribúció készítőjénél van, így azt a rendszert célszerű használnunk, amit az általunk választott disztribúció kínál. 1
A System V (System Five, röviden SysV) a nyolcvanas évek egyik sikeres UNIX-változata. Fő konkurense a BSD (Berkeley Software Distribution) volt.
21
SysV init A hagyományos SysV inittel kompatibilis megoldás található meg a Debian disztribúció aktuális kiadásában, valamint a beágyazott rendszereken is ez a jellemző. Az újabb init-rendszereket használó terjesztések is igyekeztek lehetővé tenni a SysV inithez készült szolgáltatások használatát kompatibilitási interfészek biztosításával.
Futási szintek Az init központi fogalma a futási szint (runlevel), amely a rendszer egy pillanatnyi jellemzője. Az egyes futási szinteket 0 és 6 közötti egész számokkal, valamint „S” betűvel jelöljük, amely futási szintek értelmezése az egyes rendszerekben változatos. Általánosságban elmondható, hogy a „0” jelű speciális futási szint a gép kikapcsolását, a „6” jelű pedig újraindítását jelenti. Az 1-es futási szint általában az egy felhasználós mód, amelyben olyan adminisztratív feladatokat tudunk végrehajtani, ami a szokásos szolgáltatások futása mellett nem lehetséges vagy célszerűtlen. A 2–5 futási szintek értelmezése nagyobb változatosságot mutat, a 2-es vagy 3-as szint a többfelhasználós, a szolgáltatásokat is tartalmazó futási szint, míg a 4–5-ös egyes rendszereken (például Debian) a grafikus rendszerrel bővíti a kisebb szintek szolgáltatáshalmazát. Más rendszereken a 2-es szint jelöli a teljes többfelhasználós módot, míg a nagyobb szinteket nem használják. Az „S” futási szint szerepe is változó, Debian alatt a csak bootoláskor indítandó szolgáltatások helye, más rendszereken nem használják, vagy az egyfelhasználós mód egy szinonimája. A futási szintek között az init paranccsal válthatunk, például a gép újraindításához: init 6. A rendszer betöltésekor az alapértelmezett futási szintet éri el, amelyet az init konfigurációs fájlja határoz meg. Az init működését a /etc/inittab fájlban állíthatjuk be. A fájl kettőspontokkal elválasztott mezőkből álló sorai egy-egy szolgáltatást írnak le, és egy rövid szolgáltatásazonosítóból, a szolgáltatás számára kijelölt futási szintek listájából, az indítás módjából és végül a végrehajtandó parancsból állnak. Például egy virtuális terminál futtatása a 2–5-ös futási szinteken (a respawn mód azt jelenti, hogy a programot kilépése esetén újból kell indítani): 1:2345:respawn:/sbin/getty 38400 tty1
Speciális indítási mód az initdefault, amely az alapértelmezett futási szintet jelöli. Például 3-as alapértelmezett szintet állít be a következő sor: is:3:initdefault:
rc A legtöbb esetben az inittab fájlban nem kell az alapértelmezett futási szinten és a terminálokon kívül mást beállítanunk, mivel az alapértelmezett konfiguráció egy összetettebb megoldást tartalmaz, az rc-t (runlevel change, futásiszint-váltás). Az egyes futási szintekhez tartozik egy könyvtár, általában /etc/rc[0-6S].d/ néven, amelyben init szkriptekre mutató szimbolikus linkek találhatóak. Az inittabba felvett bejegyzéseknek megfelelően az rc szkript lefut minden futásiszintváltásnál, és az ezen könyvtárakban lévő linkek alapján indítja el és állítja le a megfelelő szolgáltatásokat. Az init szkriptek a /etc/init.d/ könyvtárban találhatóak, és szolgáltatások elindítására (start), 22
leállítására (stop), állapotuk lekérdezésére (status), vagy újraindításukra (restart), újratöltésükre (reload) szolgálnak az imént megadott argumentummal futtatva. Például Debian alatt a telepített, de jelenleg nem futó Apache webkiszolgálót a /etc/init.d/apache2 start paranccsal indíthatjuk el. Ezekre az init szkriptekre mutatnak szimbolikus linkek a /etc/rc?.d/ könyvtárakból, kötött elnevezésekkel. A link első karaktere egy „S” vagy egy „K”, amely azt jelöli, hogy az adott szintre lépve az adott szolgáltatást indítani (Start), vagy leállítani (Kill) kell. Ezt követi két számjegy, amely az indítások sorrendjét adja meg – egyes szolgáltatásokat csak akkor lehet elindítani, ha másikak már futnak. A link neve a szolgáltatás nevével – ahogy az init szkript szerepel az init.d könyvtárban – fejeződik be. Például a második futási szinten 91.-ként indítandó Apache webkiszolgáló linkje a következő: /etc/rc2.d/S91apache2 -> ../init.d/apache2 . Az rc?.d könyvtárakban lévő linkek nevében szereplő prioritás a szolgáltatások indítási és leállítási sorrendjét határozzák meg: az a számok, egy prioritási szinten belül pedig betűrend szerint történik. Ez a módszer pótolja a szolgáltatások közti függőségek kezelését, amire más megoldások szofisztikáltabb lehetőségeket adnak. Jó ökölszabály, hogy egyazon szolgáltatás S és K linkjeinek prioritása összeadva 100-at adjon, mivel ha minden szolgáltatás így szerepel, akkor az indítási és a leállítási sorrend ellenkező lesz: a korábban indított szolgáltatás később áll le. Mivel ezeknek a linkeknek a karbantartása is nehézkes, ezt a disztribúciók igyekeznek megkönnyíteni. A Debian az update-rc.d parancsot biztosítja. Egy új szolgáltatás (a példákban: foobar) bekapcsolásához az alapértelmezett futási szinteken, 20/80 prioritással, futtassuk az update-rc.d foobar defaults 20 80 parancsot. Ha az init szkript elején szerepel egy speciális formátumú megjegyzés, akkor az alapértelmezett futási szinteket onnan veszi az update-rc.d, egyébként a 2–5 futási szintekre állít „S” linket. Egy szolgáltatás tiltásához először töröljük a linkeket (update-rc.d -f foobar remove), majd vegyük föl az összes futási szinthez a „K” linket: update-rc.d foobar stop 20 2 3 4 5 .. Hasonló célt szolgál a CentOS rendszereken a chkconfig parancs.
Init szkriptek írása Init szkriptet írni általában egy másik, már meglévő, jól működő alapján célszerű. A legtöbb alkalmazáshoz a csomag vagy a dokumentáció részeként tartozik init szkript is, azonban előfordulhat, hogy ez nem megfelelő, vagy más rendszerhez íródott. Egy olyan szkriptet kell írnunk, amely első argumentumától függően elindítja, leállítja vagy újraindítja a szolgáltatást. A hagyományos UNIX szolgáltatások, a daemonok végrehajtásukkor a (egy vagy két) fork rendszerhívással egy új, háttérben futó folyamatot indítanak, majd kilépnek. Az init-rc rendszer nem tartja nyilván azt, hogy egy adott szolgáltatás éppen fut-e, valamint az egyes szolgáltatások az init rendszertől függetlenül is elindulhatnak, megállhatnak (gondoljunk itt arra, hogy valaki kilövi a folyamatot, vagy az hiba miatt kilép). Ezért fel kell készülnünk arra az esetre is, amikor a szolgáltatás már fut, de start utasítást kapunk, illetve hogy olyan szolgáltatás leállítására kapunk utasítást, amely nem is fut. Erre a problémára a szokásos megoldás az elindított szolgáltatás pid-jének (process id, folyamatazonosító) nyilvántartása egy pid-fájlban. Ezt a legtöbb daemon automatikusan elkészíti /var/run/programneve.pid néven. Elindításkor ellenőriznünk kell, hogy létezik-e a pid-fájl, és ha létezik, fut-e még a benne szereplő azonosítóval a folyamat. Ha már fut, akkor nem kell újra elindítani (általában ez nem is sikerülhet, de sok gondot okozhat). Leállításkor szintén ellenőrizzük a pid fájl meglétét. Ha a benne szereplő azonosítóval fut a folyamat, azt egy TERM signallal ki kell lőni. Ezután ellenőrizni kell, hogy leállt-e véges időn belül. Ha leállt, törölhetjük a pid-fájlt, ha nem, akkor jeleznünk kell a sikertelenséget, vagy megpróbálkozhatunk az erőltetett leállítással a KILL 23
signallal. Az életciklus kezelésén kívül még az init szkript feladata a megfelelő környezet beállítása: a futtató felhasználó és csoport, a környezeti változók, a munkakönyvtár stb. A daemonok jelentős része parancssori argumentumokat is átvesz, amelyeket itt kell összeállítani. A felsorolt feladatok ismétlődő jellege miatt az egyes disztribúciók általában segítséget adnak függvénykönyvtárak és indítóprogramok formájában. Ilyen a Debian-féle start-stop-daemon program vagy a CentOS-ben található daemon függvény. Az alábbiakban egy minimális funkcionalitású, az ISC DHCP-kiszolgáló indítását és leállítását végző szkript szerepel, amely nem használja a disztribúcióspecifikus szolgáltatásokat: #!/bin/sh pidfile=/var/run/dhcpd.pid running() { [ -e $pidfile ] && pid=`cat $pidfile` && [ -n "$pid" -a -e /proc/$pid ] } start() { touch $pidfile; chown dhcpd $pidfile running || /usr/sbin/dhcpd || return 1 echo Started. } stop() { running && kill `cat $pidfile` sleep 1 && running && sleep 5 && running && echo Failed to stop. && return 1 echo Stopped. && rm -f $pidfile } case "$1" in start) start ;; stop) stop ;; restart) stop && start ;; status) running && echo Running || echo Not running ;; *) echo "Unknown command: $1" esac
Mivel egy egyszerű shell szkriptet kell írnunk, természetesen az tetszőleges feladatot végezhet az indításkor és a leállításkor, nem csak daemon indítását és megállítását. Számos példát találunk erre is disztribúciónk /etc/init.d/ könyvtárában. Az egyes szolgáltatások konfigurációjának egy részét az indításukkor kell ismerni, mivel azok a daemon indításakor, parancssori argumentumként vagy környezeti változókként adhatóak át. Ezek beállításához az init szkripteket kellene szerkeszteni. Mivel ezeket általában a csomagkezelő hozza létre és frissíti szükség esetén, külön konfigurációs fájlokat használhatunk az ilyen jellegű beállításokhoz, amelyet a gyári init szkriptek betöltenek. Ezek Debian és Ubuntu rendszereken a /etc/default/, CentOS alatt pedig a /etc/sysconfig/ könyvtárban találhatóak.
Upstart Az Upstart az Ubuntu, valamint az aktuális CentOS és RHEL disztribúciók alapértelmezett init rendszere. Konfigurációja az egyes szolgáltatások leírásából áll, amelyeket eseményvezérelt módon indít el, majd elindításuk után teljes életciklusukat felügyeli. Ennek a felügyeletnek a fő szerepe az esetleg megálló programok újbóli elindítása. Az elindítás és megállítás logikáját, visszajelzését, a folyamat azonosítójának nyilvántartását nem nem a konfigurációnak kell megoldania, azt a rendszer végzi el. 24
Vezérlése Az Upstartot használó rendszereken a folyamatok kézzel történő vezérlése az initctl paranccsal történik. Az initctl első argumentuma a parancs, a következő általában a vezérelt szolgáltatás neve. Például az apache2 szolgáltatást az initctl start apache2 paranccsal indíthatjuk el. A fontosabb parancsok önmagukban is használhatóak, a start apache2 parancs egyenértékű az előbbivel. A szolgáltatásokat vezérlő parancsok megegyeznek az init szkripteknél szokásossal: a start elindít, a stop megállít, a restart újraindít, míg a reload újratölt egy szolgáltatást. A status parancs kiírja a szolgáltatás állapotát – hogy fut-e éppen. Az initctl list paranccsal listázhatjuk az elérhető szolgáltatásokat. Az eseményvezérelt működés azt jelenti, hogy az egyes szolgáltatások indítása és leállítása nem futási szintek váltásakor történik, hanem valamilyen esemény hatására. Ezek az események lehetnek nevezetesek, mint például az init folyamat indulását jelző startup esemény, egy hálózati interfész elérhetővé válását jelző net-device-up esemény, fájlrendszerek elérhetőségét jelző filesystem esemény vagy egy másik szolgáltatás állapotváltozása, a starting, a started, a stopping és a stopped események; vagy magunk is definiálhatunk újakat. Egy esemény bekövetkeztét mi is jelezhetjük a sysctl emit esemény-neve [paméter=érték]… paranccsal.
Konfigurálása Az Upstart központi konfigurációja a /etc/init/ könyvtárban található, ahol a konfigurációs fájlok egy-egy szolgáltatást vagy feladatot írnak le, és fájlneveik kötelezően .conf-ra végződnek. Ezen felül .override végződésű fájlokat is létrehozhatunk, amelyek az azonos nevű szolgáltatás konfigurációját egészítik ki, írják felül a megadott beállításokkal. Ezeket indulásakor, valamint a fájlok változásakor automatikusan tölti be az Upstart (inotify segítségével értesül a változásokról). Szintaxisukat az init(5) kézikönyvoldal írja le részletekbe menően (man 5 init). A szolgáltatásokat leíró konfigurációs fájlok stanzákból állnak, amelyek egy-egy tulajdonságot állítanak be. A stanzák egysorosak, illetve a befejezetlen sorok végén \ karakterrel folytathatóak; vagy többsorosak, amelyek egy bevezető és egy végjel között adhatóak meg. A sor végéig tartó megjegyzéseket # karakter jelzi. A fájl elején általában az adott szolgáltatás dokumentációja szerepel: a description stanzában röviden leírhatjuk az adott szolgáltatást, az author stanza a szolgáltatásleírás szerzőjének elérhetőségét, a version a verzióját, míg a usage stanza a paraméterezhető stanzák használatát írják le. A start on és stop on stanzák azokat az eseményeket adják meg, amikor a szolgáltatást el kell indítani vagy le kell állítani. Az események ÉS (and) vagy VAGY (or) kapcsolatban lehetnek, valamint a paramétereiket is meg lehet kötni. Például a started esemény egy Upstart-szolgáltatás elindítása után következik be, és első paramétere a szolgáltatás neve. Így például a kdm, a gdm vagy a lightdm indulása után elindítandó folyamat a start on started [kg]dm or started lightdm beállítással adható meg. Fontos esemény még a runlevel, ami a futási szintre lépéskor következik be, és paramétere az új futási szint jele. Itt is a mintaillesztés használata a célszerű, például stop on [!2345] beállítással lehet kérni, hogy a gép leállásakor álljon le a szolgáltatás is. A lényegi beállítások a futtatandó programot és a futtatás módját adják meg. A legfontosabb a daemon végrehajthatójának elérési útvonala és argumentumai. Ezt az exec stanzában adhatjuk meg. Ha speciális karaktert is tartalmaz, akkor egy parancsértelmező fogja elindítani. Az exec helyett használhatjuk a script többsoros stanzát is, amelyben több parancsot adhatunk meg, amely a program elindítását végzi, majd az end script végjellel zárhatjuk le. Fontos, hogy az Upstart -e kapcsolóval indítja a parancsértelmezőt, vagyis minden parancs hibakód nélkül kell kilépjen. 25
Lényeges körülmény, hogy az Upstart alapbeállításban nem daemon típusú programokra számít, vagyis a szolgáltatás futása alatt (az indítás után) a program nem léphet ki, más szóval a szolgáltatás előtérben kell fusson, a daemonizálását az Upstart végzi el. Ezt általában a -d (daemon) kapcsoló elhagyásával, vagy a -f (foreground) kapcsoló hozzáadásával tudjuk kérni a programoktól. Ha ez nem lehetséges, az except fork (egy fork esetén) vagy az except daemon (kettő esetén) beállítással jelezhetjük. Amennyiben a szolgáltatás indítása vagy leállítása előtt vagy után szeretnénk még más parancsokat is futtatni, azt rendre a pre-start, post-start, pre-stop és post-stop script … end script stanzákkal tehetjük meg. Fontos beállítás a respawn stanza, amellyel kérhetjük, hogy az abnormálisan kilépett szolgáltatást újraindítsa az Upstart (alapbeállításban legfeljebb 5 másodpercen belül 10-szer). Az Upstart újabb változatai képesek a setuid, setgid és chroot stanzákkal a felhasználó, a csoport és a gyökérkönyvtár beállítására is. Ezeket a meglévő daemonok egy része önmaga is be tudja állítani, azonban ez egy generikusabb és biztosabb megoldás. Hasonlóan lehetőség van a PAM soft és hard limitek beállítására is: a limit core unlimited unlimited beállítás például engedélyezi a core fájlok létrehozását. Hasznos funkció a konzolkimenet sorsának beállítási lehetősége. A console log beállítás engedélyezi, a console none pedig tiltja a szabványos kimenetekre írt szöveg naplózását a /var/log/upstart/ könyvtárba. Az egyes szolgáltatások engedélyezése és tiltása a manual stanza segítségével a legegyszerűbb. Ha egy ilyen tartalmú override-fájlt helyezünk el, akkor a szolgáltatás nem fog elindulni automatikusan. Régebbi Upstart esetén kénytelenek vagyunk szerkeszteni a szolgáltatás leírását, és érvényteleníteni a start stanzát. A SysV init szakaszban bemutatott DHCP kiszolgáló minimális Upstartos konfigurációja (/etc/init/dhcpd.conf): start on runlevel [2345] stop on runlevel [!2345] exec /usr/sbin/dhcpd -f
További példákat találunk az Upstartot használó disztribúciók (különösen az Ubuntu) /etc/init/ könyvtárában. Szolgáltatásleírás fejlesztésekor gondot okozhat, hogy az Upstart automatikusan tölti be a megváltozott leírókat, így a szintaktikai hibákról nem értesülünk, amikor el akarjuk indítani a szolgáltatás, csak arról, hogy nincs ilyen nevű leíró betöltve. A hibaüzeneteket a naplóban találjuk, például a dmesg|tail paranccsal érhetjük el az utolsókat. Azt is vegyük figyelembe, hogy a restart parancs nem veszi figyelembe az leíró változtatásait, ehhez külön stop és start parancsokat kell kiadnunk.
Systemd A systemd egy új kezdeményezés, amelyet a Red Hat és a Novell fejlesztői vezetnek. A systemd disztribúcióktól független, célja az elavult SysV init kiváltása. Jelenleg a SUSE és Fedora aktuális kiadásaiban találkozhatunk vele. Fő előnye az Upstarthoz hasonlóan a párhuzamosított rendszerindítás, valamint a szolgáltatások felügyelete. Ezen felül a systemd további funkciókat is biztosít. Segítségével részben kiválthatóak az (x)inetd, cron és fstab szolgáltatások is. A systemd26
ben, az Upstarthoz hasonlóan a szolgáltatások indítását konfigurációs fájlban kell leírni, ami szükségtelenné teszi a vezérlési logika ismételt programozását. A szolgáltatás felügyelete a systemd feladata a szolgáltatás teljes életciklusa alatt. A párhuzamosítást tovább segíti, hogy nem köti a különböző üzenetküldő csatornák létrehozását az azt biztosító szolgáltatásokhoz, hanem explicit létrehozza azokat és később köti be a különböző folyamatokat.
Vezérlése A systemd-t használó rendszereken a folyamatok vezérelése a systemctl paranccsal történik. A szolgáltatások indítása-megállítása az SysV inithez és az Upstarthoz hasonlóan start, stop, status és reload parancsokkal történik. Például egy Apache webszerver indításához a systemctl start apache2 parancsot adjuk ki. Az erre felkészített szolgáltatásokat – ezek a /usr/lib/systemd/system/ mappában találhatóak –, az enable paranccsal engedélyezhetünk és a disable paranccsal tilthatjuk le, például systemctl enable sshd.service paranccsal az SSH kiszolgáló indítását tiltjuk le. Ez az engedélyezés vagy tiltás parancs egy szimbolikus linket helyez el vagy töröl a /etc/systemd/system/ könyvtárban az egyes futási szintek elvárt szolgáltatásait tartalmazó alkönyvtárban (például a multi-user.target.wants/-ban). A systemd a futási szinteket események helyett targetekkel (célokkal) valósítja meg: a megszokott futási szintnek megfelelő célok el elérhetőek a futási szint száma szerint (runlevel2.target), vagy beszédes névvel (multi-user.target – ami a runlevel2.target egy álneve). Érdemes megemlíteni a snapshot parancsot, amelynek segítségével futtatási állapotokat, a systemd teljes állapotterét menthetünk el (új targetekként). Ezeket a célokat az isolate paranccsal lehet betölteni – hatása lényegében a futásiszint-váltásnak felel meg.
Konfigurálása A systemd konfigurációs fájljai a unitok. Minden fájl INI jellegű kulcs=érték párokból áll, amelyek [Szakaszok]-ra oszthatóak (mint a kötelező [Unit] szakasz). Emellett a fájl kiterjesztése határozza meg a konfiguráció típusát (név.típus). Ez általában service, amely egy szolgáltatást ír le. Ezen kívül lehet socket a különböző adatkapcsolatokhoz, device az eszközökhöz, mount, automount a fájlrendszerekhez. A timer típusú konfigurációk a ciklikus végrehajtású feladatokat adják meg (ezzel tölti be a cron szerepét a systemd). Részletesebben egy service fájl paramétereivel foglalkozunk. Teljes leírást a systemd.unit(5) kézikönyvoldalon találunk (man 5 systemd.unit). Mint minden systemd konfigurációs fájlnak, a szolgáltatásleíróknak is van egy [Unit] és egy opcionális [Install] blokkja. A [Unit] blokkon belül kell megadnunk a unit leírását (Description), és a különböző indítással kapcsolatos paramétereket. A számos speciális függőségi eset közül kettőre lehet szükségünk a gyakorlatban. A Requires esetén az itt felsorolt unitok is aktiválásra kerülnek és a szolgáltatásunkkal együtt indulnak el, de ha bármelyik leáll, akkor a mi szolgáltatásunk is le lesz állítva. A Wants a Requires-hez hasonló, de engedékenyebb: csak az indítást kérjük, nem törődünk annak sikerességével. Az indítások sorrendjét az After és Before opciók segítségével lehet megadni. Ezekkel kötheti ki egy szolgáltatás, hogy egy másik után (After) vagy előtt (Before) induljon. Lehetőség van negatív függőségek megadására a Conflicts opcióval: a Conflicts-ban szereplő szolgáltatások futása megakadályozza a mi szolgáltatásunk indítását. A szolgáltatással kapcsolatos beállításokat a [Service] blokkban adhatjuk meg. A szolgáltatás konkrét indítási parancsát az ExecStart-ban adhatjuk meg. Lehetőség van az indítás előtt és után is további parancsokat futtatni az ExecStartPre és ExecStartPost beállításokkal. Ezekből az 27
opciókból több is szerepelhet. Ha a daemon forkol, ezt a Type mezőben jelezhetjük a forking paraméterrel. Amennyiben nem lenne megfelelő a TERM signal küldése a folyamat leállítására, az ExecStop opcióval adhatunk meg parancsot. (Segítségünkre lehet, hogy konfigurációs fájlban lehetőség van változók használatára is ilyen pl.: $MAINPID, ami az elindított szolgáltatás pidje.) Érdemes megemlíteni az ExecReload opciót, ami a systemctl reload parancsnál futtatandó parancsot adhatjuk meg. Az Upstart respawn stanzájához hasonlóan lehetőség van a folyamatok újraindítására a Restart paraméter segítségével. Lehetséges értékei a no, on-abort és az on-failure. A no esetén nem történik automatikus újraindítás, on-failure esetén abban az esetben, ha a kilépési kód nem 0, az on-abort beállítással pedig az ismeretlen okból kilépett folyamatot indítja újra a systemd. Az always beállítás segítségével minden esetben újraindul. Az újraindítás előtt kivárandó időt a RestartSec-kel adhatjuk meg, például 20sec formában. A futtatási környezet is testre szabhatjuk. Az Environment opció segítségével adhatunk át környezeti változókat, egymás után felsorolva szóközzel és idézőjellel elválasztva (Environment="PATH=/usr/bin:/bin" "LANG=C"). A daemon felhasználóját és csoportját a User és Group beállítással állíthatjuk roottól eltérőre. A gyökérkönyvtárat a RootDirectory paraméterrel állíthatjuk be (chroot). Végül az init telepítéséért felelős [Install] blokkot kell beállítani. Ezt a systemd csak a systemctl enable és disable parancsok végrehajtásakor értelmezi (később nem). A szolgáltatáscsoportokat itt állíthatjuk be: a WantedBy, RequiredBy beállításokban felsorolt csoportok a Wants és Requires beállításhoz hasonlóan működnek. Az enable parancs ez alapján hozza létre a szimbolikus linkeket a megfelelő groupname.wants vagy groupname.requires könyvtárakban. Az Also beállításban további szolgáltatások telepítését kérhetjük. A korábbi szakaszokban bemutatott DHCP szolgáltatást leíró systemd konfigurációs fájl a következő lenne: [Unit] Description=DHCPD service systemd init configuration [Service] ExecStart=/usr/sbin/dhcpd -f [Install] WantedBy=multi-user.target
Rendszerkomponensek konfigurálása Mint az már a korábbi szakaszokból is kiderült, a Linux rendszerek konfigurálásának elsődleges színtere a /etc/ könyvtár, az abban lévő különböző konfigurációs fájlok. Egy új szoftver megismerésekor jogosan keressük a konfigurációját, amit általában meg is találunk a /etc/programneve/ könyvtárban, vagy a /etc/programneve.conf, esetleg /etc/programneverc nevű fájlban. A konfigurációs fájlok felépítése változatos. Egy részük kulcs=érték jellegű beállításokból áll esetleg szakaszokra bontva, míg más esetekben shell szkripteket találunk itt. Az is előfordul, hogy egy programnak saját nyelve van, amelyen szkripteket lehet írni. Jellemző forma még táblázatos adatok tárolására a kettőspontokkal vagy szóközökkel elválasztott mezőkből álló rekordokból felépített lista. Nem tartozik a konfigurációhoz, így ne is keressük a /etc/ alatt a különböző szolgáltatásokhoz tartozó adatfájlokat, átmeneti fájlokat, naplóállományokat. Ezek a változó adatok a /var/ könyvtárban találhatóak (újabban ezen kívül a /srv/ és a /run/ alatt is). Kevés kivételtől eltekintve a /etc/ alatti fájlok nem változnak a rendszer normál működése közben, ha nem változtattunk konfigurációt. 28
A legtöbb szoftver használható alapbeállításokkal érkezik, amelyeket megjegyzésekkel bőségesen ellátott konfigurációs példafájlban adnak meg. Egyszerűbb esetekben ez is elegendő lehet a kezdeti beállítások megtételéhez. Ha ez nem volna elegendő, az alkalmazás dokumentációjában találjuk a konfiguráció részleteit. Az egyes konfigurációs fájlok formátuma a man-ban is szerepel, az ötös kötetben. Így ha például a /etc/passwd fájl formátumára vagyunk kíváncsiak, a man 5 passwd paranccsal nézhetünk utána a leggyorsabban. Példaként említettük már a passwd fájlt, amely a felhasználói adatbázist tartalmazza (nevével szemben a jelszavakat már nem). Hasznos lehet egy rendszer kiadásának felderítéséhez a /etc/issue fájl is. Az egyes disztribúciók némileg egységesíteni próbálták a rendszerbeállításokat, így a különböző disztribúciók konfigurációs fájljai között jelentős különbségek alakultak ki. Például Debian alatt számos szolgáltatás paraméterei a /etc/default/ alatt találhatóak, amit kisebb mértékben mások is átvettek. A RHEL/CentOS rendszeren pedig ennél valamivel szélesebb körű konfiguráció található a /etc/sysconfig/ mappában. A konfiguráció kezelése szakértelmet és figyelmet igényel, egy-egy félrekonfigurálással a rendszer működésképtelenségét lehet okozni. Az ilyen hibák felderítése sem mindig egyszerű. Az is előfordulhat, hogy egy módosítás negatív hatása hosszú ideig lappang, és utólag már nehéz kinyomozni, hogy mi történt. Mindezek a problémák hatványozottan jelentkeznek, ha több rendszergazda jelentős számú szervert tart közösen üzemben. A probléma kezelésére több megoldás is adódik. Minimális befektetést igényel a szoftverfejlesztésben széles körben elterjedt verziókezelők használata: tároljuk a teljes /etc/ könyvtárat egy repositoryban. Ehhez jól bevált megoldás a népszerű elosztott verziókezelő, a git. Mivel a konfiguráció időnként – különösen csomagfrissítések alkalmával – automatikusan is változik, ezért a kézi verziókezelés nem mindig elegendő. Ezt a problémát oldja meg az etckeeper, amely automatikusan commitolja az ilyen módosításokat. Ennél több erőfeszítést igényel egy konfigurációmenedzsment-eszköz bevezetése (divatos nevén: DevOps), ami viszont jelentősen robusztusabbá teszi a nagyobb infrastruktúrák konfigurációját.
29
Általános célú hálózati szerver: az inetd és xinetd A hálózati szolgáltatásokat nyújtó szoftverek jellemzően olyan háttérben futó programok, amelyek az operációs rendszer és a függvénykönyvtárak átviteli-rétegbeli absztrakcióit használva hallgatnak egy-egy TCP vagy UDP porton, majd ha egy ügyfél kapcsolatot kezdeményez, azt egy másik szálon vagy folyamatban szolgálják ki. Könnyen belátható, hogy minden hasonlóan működő szolgáltatás folyamatosan erőforrásokat – különösen memóriát – használnak, valamint azonos funkciókat kell a fejlesztőknek megvalósítaniuk, felelősségi körükben tartaniuk. Ezen felismerés nyomán jött létre az inetd, az „internetes szuperszerver”. Az általános célú hálózati kiszolgáló egy olyan szolgáltatás, amely egyszerre hallgat több TCP és UDP porton, több szolgáltatást kiszolgálva, majd ha a portok valamelyikére kérés érkezik, megválaszolására egy új folyamatban elindítja a konfigurációnak megfelelő programot, amelynek egyrészt a hálózati kommunikáció részleteivel már nem kell foglalkoznia, másrészt a programot csak lekérés esetén kell elindítani. Ezzel a ritkábban használt szolgáltatások erőforrást, folyamatokat takaríthatnak meg, azonban teljesítménye a modern kiszolgálóalkalmazások nagy terhelésre optimalizált párhuzamos futtatási megoldásaival ritkán mérhető össze. Használata nagy forgalmú, komplex kiszolgálófeladatok futtatására napjainkban nem jellemző, azonban egyes egyszerűbb, ritkán vagy kevés ügyfél által használt szolgáltatások – tftp, ident, nrpe, git – vagy prototípus-rendszerek futtatására, valamint beágyazott rendszereken gyakran alkalmazzák. A démonként futni képes hálózati szolgáltatások maguk végzik a beérkező hálózati kapcsolatok fogadását és a kezelésükhöz szükséges folyamatok vagy szálak indítását, életciklusuk felügyeletét. Ennek a helyes megvalósítása nem könnyű feladat – sok esetben erre nincs is szükség, mivel pontosan ezt a felelősséget veszi át az alkalmazástól az inetd: az alkalmazásnak csupán egyetlen kapcsolatot kell feldolgoznia, és különleges hálózati feladatai sincsenek, a kommunikáció egyszerűen a szabványos kiés bemenetén keresztül zajlik. Nehézkesen működik azonban ez a megoldás nagy számú kapcsolat esetén, mivel nincs lehetőség az adott szolgáltatásra optimalizált erőforrástakarékos párhuzamosítási technikák használatára. Az általános célú hálózati kiszolgálónak két ismert megvalósítása a hagyományos inetd és továbbfejlesztett változata, a xinetd.
Inetd A szolgáltatás eredeti, BSD-ből származó megvalósítása az inetd. Hosszú története miatt számos változatban érhető el, azonban a GNU/Linux rendszereken jelentős részben kiszorította fejlettebb változata, a xinetd. Debian és Ubuntu rendszereken az openbsd-inetd nevű csomagokban találjuk meg támogatott változatát, míg a CentOS tárolói nem is tartalmazzák. Az inetd indítása és leállítása a szokásos módon történik, például a fenti csomag esetén a sudo /etc/init.d/openbsd-inetd start, valamint a sudo /etc/init.d/openbsd-inetd stop 30
parancsokkal. Ha nincs szolgáltatás konfigurálva, az inetd nem indul el. Amennyiben egy szolgáltatást az inetd-vel szeretnénk kiszolgálni, ellenőrizzük, hogy az adott szolgáltatás szerepel-e a TCP- és UDP-portok központi nyilvántartásában, a /etc/services fájlban. Ez a fájl egy szimbolikus elnevezéshez egy portszámot és egy protokollt ad meg, majd szükség esetén álneveket sorol fel. tftp nrpe
69/udp 5666/tcp
# Nagios Remote Plugin Executor
Ha a listában nem szereplő portot szeretnénk használni, ellenőrizzük, hogy nem szerepel-e más néven az adott port, majd vegyük fel a listába. Ezután nyissuk meg a /etc/inetd.conf konfigurációs fájlt. Ebben alapesetben egy szolgáltatás sem szerepel, csupán # jellel kezdődő megjegyzések, amelyek röviden bemutatják a fájl formátumát. A fájlban egy szolgáltatást egy sorban, a mezőket szóközökkel elválasztva kell leírnunk, a következő sorrendben: •
Szolgáltatás neve, ahogy a /etc/services-ben szerepel (például nrpe).
Átviteli-rétegbeli protokoll: tcp vagy udp – ahogy a /etc/services-ben szerepel. Ha a szolgáltatás tcp-vel és udp-vel is szerepel, válasszunk, vagy két külön sorban, mindkét változatban konfiguráljuk.
•
Kapcsolók: wait vagy nowait – várja, vagy ne várja meg az előző kiszolgálófolyamat kilépését újabb szolgáltatás kiszolgálásához. Tipikus beállítása UDP esetén wait, TCP esetén nowait.
•
Felhasználó: a szerverprogram ezen felhasználó (vagy user:group formában megadva ezen felhasználó és csoport) nevében kerül futtatásra. Lehetőség szerint ne adjuk meg a root felhasználót.
•
Szerverprogram útvonala: a szerverprogram futtatható fájljának abszolút elérési útvonala (például /usr/sbin/nrpe).
•
Argumentumok: a programnak átadandó parancssor – a program neve és az argumentumok (például nrpe -i -c /etc/nagios/nrpe.cfg).
Amennyiben az inetd használatára felkészített szoftvert használunk, a dokumentációjában meg fogjuk találni a javasolt beállítást, és a csomagkezelők is gyakran elvégzik a szükséges konfigurációt: például Ubuntu alatt a tftpd csomagot telepítve a /etc/inetd.conf fájlban megjelenik a következő sor: tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /srv/tftp
Ha a kívánt szolgáltatás nem szerepel még a konfigurációs fájlban, vegyük fel a leírását az ismertetett formátumban. Ezután indítsuk el a kiszolgálót vagy tölsük újra a beállításait, például a sudo /etc/init.d/openbsd-inetd reload paranccsal. TCP porton hallgató kiszolgáló is használható az inetd-vel. Például a Nagios állapotmonitorozó rendszerhez (hivatkozás) állapotinformációt szolgáltató nrpe ágens beállításához helyezzük el a /etc/inetd.conf-ban a következő sort: 31
Az így létrehozott szolgáltatás az nrpe (5666/tcp) portra csatlakozó kliensek kéréseit az nrpe nevű programmal szolgálja ki, amely az argumentumoknak megfelelően a megadott konfigurációs fájlt használja, és inetd üzemmódban indul. Ki is próbálhatjuk a szolgáltatást az /usr/lib/nagios/plugins/check_nrpe -H localhost -c check_load paranccsal.
Xinetd Az inetd egyszerűsége miatt számos, főleg biztonsági elvárásnak nem tudott megfelelni. Emellett konfigurációja nehézkes, és új funkciók bevezetésével tovább bonyolódna. Ezekre a problémákra ad választ a xinetd. Alapvető funkciói megegyeznek az inetd-vel, azonban könnyebben kezelhető konfigurációs formátumot használ, és olyan beállításokat is meg lehet adni az egyes szolgáltatásokra, mint hogy melyik interfészen hallgassanak, mely lekérésekre válaszoljon, vagy mely eseményeket naplózza. Konfigurációs fájlja a /etc/xinetd.conf, azonban alapbeállításban a /etc/xinetd.d/ könyvtárban lévő fájlokat tartalmát is hozzáfűzi konfigurációjához. A fájl szolgáltatásdefiníciókból áll, amelyek a service kulcsszóból, a szolgáltatás nevéből, majd kapcsos zárójelek között kulcs=érték formában megadott paraméterekből állnak. A fentebb ismertetett nrpe-szolgáltatás xinetd formátumú leírása például: service nrpe { socket_type = stream wait = no user = nobody server = /usr/sbin/nrpe server_args = -i -c /etc/nagios/nrpe.cfg }
A fontosabb beállításokat az 1. táblázat. táblázat mutatja be.
32
Paraméter
Leírás
Példák
socket_type
Socket típusa.
stream dgram
(TCP esetén)
(UDP esetén)
tcp udp
protocol
Átviteli-rétegbeli protokoll – ahogy a /etc/services-ben szerepel. Ha a szolgáltatás tcpvel és udp-vel is szerepel, válasszunk, vagy két külön definícióban, mindkét változatban konfiguráljuk. Elhagyható.
wait
Várja (yes), vagy ne várja meg yes no (no) az előző kiszolgálófolyamat kilépését újabb szolgáltatás kiszolgálásához. Tipikus beállítása UDP esetén yes, TCP esetén no.
user
Felhasználó: a szerverprogram nobody ezen felhasználó nevében kerül futtatásra. Lehetőség szerint ne adjuk meg a root felhasználót.
server
Szerverprogram útvonala: a szerverprogram futtatható fájljának abszolút elérési útvonala.
server_args
A programnak átadandó további daemon --inetd –exportall /home/git/repo argumentumok.
cps
Kapcsolatok másodpercenként. 50 10 Két számot vár, az első megadja, hogy másodpercenként hány kapcsolat után függessze fel a kiszolgálást, a második számmal megadott másodpercre.
per_source
Forrás IP címenként a megadott 10 számú kapcsolatot kezel egyidejűleg.
disable
A szolgáltatás tiltása (yes esetén).
33
/usr/bin/git
yes no
1. táblázat: A xinetd szolgáltatások paraméterei. CentOS alatt a tftp-server csomagot telepítve a /etc/xinetd.d/tftp konfigurációs fájl jön létre a következő tartalommal: service tftp { socket_type protocol wait user server server_args disable per_source cps flags }
Magas rendelkezésre állás alapok: hogy ne legyen egy hetes kiesés az elromlott diszk miatt Az informatikai rendszerek fontos jellemzője a rendelkezésre állás: az idő mekkora részében tudják ellátni a rájuk bízott feladatokat. Egy lakossági szolgáltatásnál elfogadott érték lehet például a 99,5%-os éves rendelkezésre állás (sőt, akár 98% is), azonban ennek garantálása is erőfeszítéseket igényel a legegyszerűbb szolgáltatás esetén is – két napnyi kiesés egy péntek esti hardverhiba esetén sem fér bele ebbe a szolgáltatási szintbe. Más szegmensekben ennél nagyobb elvárások vannak: gyakran egyszerűen csak a „kilencesek” számát adják meg: egy „öt kilences” rendszer 99,999% rendelkezésre állást vállal. A telekommunikációban nem szokatlan ez az elvárás sem – évi 5 perc kimaradást enged meg. Szervezetek vagy nagyobb szervezeti egységek közötti szolgáltatások esetén az elvárt rendelkezésre állást a szolgáltatásszint-megállapodásban (service level agreement, SLA) rögzítik. Ez a megállapodás általában nem számolja bele a tervezett üzemszüneteket a rendelkezésre állásba, azonban külön megszabja idejüket és gyakoriságukat is. A rendelkezésre állás növelésére, magas szinten tartására irányuló megoldásokat a HA (high availability, nagy [vagy magas szintű] rendelkezésre állás) betűszóval jelöljük. Mivel olyan eszköz nincsen, ami garantáltan teljesít egy nagy rendelkezésre állási kritériumot, ezért a megoldások alapja az azonos célt ellátó eszközök többszörözése, redundáns rendszer kialakítása. Ha a redundáns eszközök bármikor át tudják venni egymás szerepét, vagy a szerepátvételt vezérlő eszköz jelentősen jobb rendelkezésre állást tud biztosítani az eszközöknél, akkor a két eszköz hibaarányát összeszorozva kapjuk a közös hibaarányt. Például ha két 1% valószínűséggel meghibásodó eszközünk van, amelyek egymástól függetlenül hibásodhatnak meg, és csak egyidejű hibájuk okoz szolgáltatáskiesést, akkor 0,012 = 0,0001 = 0,01% közös meghibásodási értéket, vagyis 99,99% működési valószínűséget kapunk. Bár ez az egyszerű modell összemossa a rendszer rendelkezésre állását az eszközök hibátlan működésének valószínűségével, a gyakorlatban jól használható a redundáns eszközök szerepének vizsgálatára. Összehasonlításként: ha mindkét ilyen eszköz szükséges a működéshez, akkor már a rendelkezésre állást szorozhatjuk össze, így a 99%-ból 98% lesz. A redundancia mértékét mindig az elvárások és a gazdasági lehetőségek alapján kell mérlegelni. A rendelkezésre állás növelését több irányban kezdhetjük el – azonban sok rendszernek ezek a módszerek közül többet is alkalmaznia kell a megfelelő szint eléréséhez.
Megbízhatóbb eszközök Az első lépések általában a hardverhibából eredő szolgáltatáskiesés valószínűségének csökkentését célozzák. Jelentősen csökkentheti a meghibásodás valószínűségét, ha a szolgáltatást folyamatos üzemre tervezett hardverrel nyújtjuk. A leggyakrabban meghibásodó elemek a lemezek és a tápegységek. A lemezek esetében megbízhatóbbak a folyamatos üzemre tervezett változatok, valamint a többportos lemezek ezt támogató vezérlővel. Mivel egy nagyobb rendszerben elkerülhetetlen, hogy egy-egy lemez időnként tönkremenjen, ezért 35
a RAID konfiguráció minden esetben indokolt lehet. RAID esetén mérlegelnünk kell a szükséges teljesítményt és a rendelkezésre álló lemezek számát is (részletekért lásd a Diszkek kezelése című fejezetet). A redundáns tápegység is jelentősen javíthatja a rendelkezésre állást: nemcsak a tápegység meghibásodása ellen véd, hanem lehetőség van több független feszültségforrás használatára, szünetmentes tápegység cseréjére stb. Célszerű a hálózati kapcsolatot is redundánsan kialakítani, erre az STP (feszítőfa-protokoll) vagy a link-aggregáció (más neveken: bond, trunk, EtherChannel) jó lehetőség.
Tartalékgép Az eszközök megbízhatóságának javításával nem lehet egy szinten túl gazdaságosan növelni a rendelkezésre állást, hiszen az esetleg mégis bekövetkező hiba helyreállítása is időt vesz igénybe. Az egy gép megbízhatóságának növelését egy hidegtartalék beállításával tudjuk kiegészíteni. Ez egy olyan gép, amely alapesetben nincs bekapcsolva, azonban a másik gép helyére bármikor betehető, és bekapcsolása után képes a szolgáltatás nyújtását folytatni. Cserélhető lemezeszközökkel rendelkező gépeknél az is egy jó megoldás lehet, ha a hidegtartalék gépbe át kell rakni a lemezeket, azonban ilyenkor készüljünk fel az olyan kellemetlenségekre, mint hogy a hálózati interfészeknek eltérő MAC címe lehet (és a modern rendszereken emiatt új interfésznevet is kapnak). Több gép esetén az is lehetséges, hogy csak egy, közös hidegtartalékot tartunk.
Klaszter A hidegtartalék elindítása, üzembe helyezése azonban általában fizikai jelenlétet, de mindenképpen emberi beavatkozást igényel, ezért hosszabb ideig is tarthat a kimaradás. Erre a problémára jelent megoldást a klaszter (cluster, fürt) architektúra. A megoldás alapja, hogy több azonos célt ellátó rendszer fut szoros hálózati összeköttetésben, amelyek vagy át tudják venni egymás feladatát (HA cluster), vagy elosztják egymás között a terhelést (HPC [high performance computing] cluster). A HPC cluster a legtöbb esetben megköveteli egy, a terheléselosztást végző belépési pont meglétét, ezért önmagában a rendelkezésre állás növelésére nem alkalmas – azonban lehetséges a két megoldás kombinálása is. A hagyományos HA clustert tekinthetjük melegtartalékos rendszernek is, amelyben a tartalék rendszer állandóan üzemben van, és azonnal képes átvenni a meghibásodott rendszer feladatait. Ezt nevezik aktív-passzív rendszernek is. Az aktív-aktív rendszer esetén a nagy rendelkezésre állást biztosító rendszer minden tagja szolgáltatást biztosít, azonban üzemzavar esetén a korábbi feladatok ellátása mellett az elromlott rendszer feladatait is átveszi.
Heartbeat A feladatok átvételét a legáltalánosabb esetben úgy oldjuk meg, hogy a tartalék rendszer IP szinten veszi át a pótolt rendszer szerepét: fölveszi IP címét. Ennek a megvalósítása figyelmet igényel, mivel biztosan tudnunk kell, hogy a másik rendszer már nem üzemel (legalábbis azon a címen), hiszen ellenkező esetben címütközést okozunk, és egy működő rendszert döntünk össze a beavatkozással. Ennek elterjedt megvalósítása a heartbeat (szívverés) módszer. Ebben az esetben az éles és a 36
tartalék rendszert egy külön erre a célra szolgáló hálózati úton kötjük össze, amelyen az éles rendszer szívverésszerűen jelzi, hogy még működik. Amennyiben a szívverés megszűnik, a tartalék rendszer körültekintően meg kell állapítsa, hogy a másik gép valóban megállt, és ekkor veheti át a feladatot.
Virtuális IP cím Az egyes gépek elérhetősége és a visszaállás megkönnyítése érdekében a szolgáltatás igénybevételére egy a gépektől független címet szokás használni, amelyet az éppen aktív gép második címként vesz föl a hálózati interfészén. Ennek esetleges alternatívája az, hogy a tűzfal hálózati címfordítással a megfelelő gépre küldi a kéréseket. Ha az egy IP cím átkerül egy másik interfészre, arról a külvilágnak értesülnie kell. A legtöbb esetben ARP kérésekkel tájékozódik a többi eszköz a gép helyéről. Mivel a hálózaton lévő eszközök ARP táblát tartanak fönt, amelyben eltárolják a válaszokat, ezért nem biztos, hogy azonnal az új interfésznek küldik a csomagokat. Ezt elkerülendő célszerű a változást meghirdetni a hálózaton, például az arping eszközzel.
Osztott tár A feladat átvételéhez általában szükség van arra, hogy a tartalékgép is elérje a szükséges tárterületet. Ennek számos módja van: amennyiben a tárterület SAN vagy NAS eszközön található, a másik gép leállása után nincs akadálya átvételének. Szoftveres megoldások is vannak a tárterület folyamatos elosztott replikálására, ilyen a Ceph vagy a GlusterFS. NAS jellegű rendszerek esetén, amelyeket általában NFS-en érhetünk el, az egyidejű elérés megoldott, SAN eszközöknél viszont a blokkeszközhöz férünk hozzá, aminek az egyidejű használatához ezt támogató fájlrendszer szükséges. Ilyen például a GFS2. Bizonyos esetekben nincs szükség az osztott tárra, mivel a replikációt alkalmazás szinten is meg lehet oldani, vagy nincs is szükség rá. Ilyen lehet egy adatbázis- vagy alkalmazáskiszolgáló, vagy éppen egy tűzfal vagy névkiszolgáló. Ha van erre lehetőségünk, akkor éljünk vele – hiszen az osztott tár redundanciáját ebben az esetben nem kell megoldanunk. Amennyiben van osztott tár, az felhasználható a feladat átadásának visszaigazolására is utolsó lehetőségként.
Példa: nagy rendelkezésre állású webkiszolgáló Két gépből álló HA klaszterrel szeretnénk kiszolgálni egy weboldalt. Az adatokat NFS-en keresztül, hálózaton érjük el egy megbízható táreszközről. A gépeknek van egy-egy adminisztratív IP címe, amelyen keresztül elérhetőek. A szolgáltatást egy harmadik, virtuális IP címen keresztül érhetik el a felhasználók, amely alapesetben a node1 nevű gépé, hiba esetén pedig a node2 húzza fel. Mindkét gépre telepítjük a szolgáltatás nyújtásához szükséges kiszolgálót, beállítjuk az NFS-elérést. A két gépnek helyesen legyen beállítva a gépneve – a példában node1 és node2, és az órák szinkronizációja is jó ötlet. A szolgáltatás átvételének megvalósításához telepítsük a Linux-HA projekt heartbeat csomagját, és végezzük el a konfigurációját mindkét gépen: A /etc/ha.d/ha.cf fájlban kell megadni az átvétel különböző pillanatainak időzítését, a kommunikáció módját és a klaszter elemeit. A deadtime beállítással azt adjuk meg, hogy hány 37
másodperc inaktivitás után kezdődjön meg az átállás. Az initdead a heartbeat indításakor a szolgáltatás beindulására adott határidő másodpercben. A bcast opció után hálózati interfészeket sorolhatunk fel, amelyeken az életjelet broadcast-olja a rendszer. Az auto_failback opcióval beállíthatjuk, hogy az elsődleges gép helyreálltával kerüljön rá vissza a szolgáltatás. A node beállítással soroljuk föl a cluster elemeit (gépnevek formájában). Például: deadtime 5 initdead 15 bcast eth0 auto_failback on node node1 node2 use_logd yes
Ezen kívül meg kell adnunk az authentikáció módját a /etc/ha.d/authkeys fájlban. Először kijelöljük az auth beállítással, hogy az 1-es számú osztott titkot használjuk üzeneteink küldéséhez, majd felsoroljuk az elfogadható bejövő kulcsokat (sorszám, titkosítás módja, közös titok): auth 1 1 sha1 TitkosJelszo
Végül be kell állítanunk az elsődleges gép nevét (pontosan úgy, ahogy a uname -n parancs kiírja), a virtuális IP címet prefixhosszal és interfésszel, valamint az átvételkor indítandó és visszaálláskor leállítandó szolgáltatások nevét a /etc/ha.d/haresources fájlban: node1 IPaddr::192.168.100.100/24/eth0 apache2
Az indítandó és leállítandó szolgáltatásokat a rendszer a /etc/ha.d/resource.d/ és a /etc/init.d/ könyvtárakban keresi, és a szolgáltatás átvételekor start, átadásakor stop paraméterrel hívja meg. Ez a webkiszolgáló esetén nem feltétlenül szükséges, akár állandóan futhat is minkét gépen. Egy adatbázis-kiszolgáló esetén viszont célszerű első szolgáltatásként egy konzisztencia-ellenőrzést fölvenni, és csak ezután engedni az adatbázis-kezelőt elindítani. Ezt az egyszerű konfigurációt mindenképpen érdemes kiegészíteni egy második hálózati összeköttetéssel, amelyen csak a klaszter tagjai kommunikálnak egymással. Ehhez a bcast beállításnál a másik interfészt kell megadnunk.
