• 1. A feladat felmérése - skálázhatóság, alternatívák, hardver.
• 2. Költségek becslése mintapélda alapján.
• 3. Biztonság
  • 3.1 Milyen programok lehetnek / nem lehetnek egy Web-szerveren?
  • 3.2 A partíciók megtervezése általánosan és a mintapéldához
  • 3.3 A biztonsági mentés (backup) lehetőségei, módszerei és javasolt paraméterei
  • 3.4 Szoftveres UPS (szünetmentes tápegység) felügyelet soros porton keresztül
  • 3.5 A szükséges felhasználók/csoportok és a lemezkvóta megtervezése

A cégnél tehát összeül a döntéshozó és a szakember, hogy megbeszéljék a rendszer tervét. A vezetőség kifejti elképzeléseit, igényeit a rendszerrel szemben felhasználói szemszögből. A rendszergazda ennek alapján összeállítja a hardver és az Internet / hálózat tervét, majd költségbecslést készít. A cég megjelöli, hogy milyen domén-neveket kíván bejegyezni. A rendszergazda, vagy a leendő Internet szolgáltató bejegyezteti a domén-neveket. (Esetünkben a boresszormegyar.hu, borgyar.hu, szormegyar.hu domének lesznek bejegyezve.)

1. A feladat felmérése - skálázhatóság, alternatívák, hardver.

Fontos kérdés esetünkben az, hogy a Web-szerverünk mekkora forgalmat fog lebonyolítani. Ennek mértékét találat/percben is megadhatjuk. Természetesen ez a különböző napszakokban eléggé változó lehet. Lényeges tehát, hogy ha egy egyszerű információs oldalról van szó, nem kell egy erőgépet vennünk. Ha már elektronikus áruházat is üzemeltetünk nagy számú klienssel, megfontolható nagyobb, esetleg nem PC architektúrájú gép vásárlása. A mi esetünkben talán még a cégnél meglévő egyik Pentium-os gép is megteszi. Minimális konfigurációnak ajánlott egy Pentium 166, 32MB RAM, 2 GB HD paraméterű gép. Nagyobb forgalom és nagyobb Web-hely esetén egy Celeron 400-as 128MB RAM és 6 GB lemez is megteszi. Extrém nagy forgalom (és CPU terhelés) esetén válasszunk nagyobb, esetleg duál-processzoros hardvert. Nem hiszem, hogy sok cég megengedhetné magának nem-x86 architektúrájú gépek beszerzését - bár azok véleményem szerint sokkal jobb hardverek, csak elterjedésüket gátolja magas áruk.

Fontos, hogy a hálózati kártya jó minőségű (pl. PCI-os 10/100 Mb/sec-es Ethernet) legyen, mert ez köt össze a router-el / tűzfallal, ez vezet a külvilágba. Természetesen fontos kérdés a sávszélesség a külvilág felé. Ez alapesetben egy 64/128k-s ISDN vonal is lehet, nagyobb forgalom esetén pl. egy 1Mb-es bérelt vonal.

Amit fontos: a hardver egységek Linux-kompatibilisek legyenek. Linux-kompatibilis hardverek: http://lhd.datapower.com, http://www.linuxhardware.net. Olvassuk el a Linux Hardware Compatibility HOWTO-t.:http://www.linuxdoc.org/HOWTO/Hardware-HOWTO.html. Főleg az alaplapon ne spóroljunk, legyen egy minőségi IDE vezérlő chipset rajta (pl. i440bx). Ha SCSI kártyát és merevlemezt veszünk, akkor javasolt pl. az Adaptec cég PCI-os SCSI kártyáit választani. Egyszerű információforrás maga a kernel: egy make *config-al⁸⁸ egy teljes körű listát kapunk a Linux által támogatott hardverektől. Továbbá a kernelforrás Documentation könyvtárában is megfelelő információkhoz lehet jutni. Tudni kell, hogy a kernelben nem egy adott cég adott terméke, hanem általában annak a vezérlő-chip-je van felsorolva (leprogramozva), hiszen több termék is használhatja ugyanazt a vezérlőt. Ezért ne ijedjünk meg, hanem olvassuk át a hardver dokumentációkat, hogy melyik eszköz milyen vezérlővel rendelkezik.

Ha a cégnél jelenleg is van egy erre a feladatra kijelölhető szabad gép, akkor már csak a szoftvert és az Internet-kapcsolatot kell beszereznünk. Ha nincs, akkor keressünk fel néhány számítástechnikai üzletet és szerezzük be a hardveregységeket, majd szereljük azokat össze. Ma már egy PC összeszerelése gyerekjáték, ha megfelelően választottuk meg az összetevőket. Erre itt nem térek ki, de ajánlom a következő szakirodalmat: [6].

A lényeg az, hogy mielőtt nekikezdenénk installálni a rendszert, tájékozódjunk részletesen a hardverünk Linux-kompatibilitásáról, hogy ne érjen munka közben meglepetés.

A mintapéldámban egy fiktív Bőr és Szőrmegyártó Kft. esetét vizsgálom. A menedzsment úgy határozott, hogy belépnek az elektronikus kereskedelembe, és első lépésként információkat közölnek termékeikről, szolgáltatásaikról több nyelven is az Interneten. Második lépésben pedig esetleg Online áruházat nyitnak a Web-helyükön (ezt a lépést nem tárgyalom). Mivel nincs még tapasztalatuk e téren, ezért először nem szeretnének sok pénzt fektetni a dologba. Ekkor jön a viszonylag kis teljesítményű kis költségű házi Linux-os rendszer a számításba. Felkérik a rendszergazdát, hogy szerezzen be információkat és tervezze meg a rendszert. A rendszergazda kiválasztja és összerakja a hardvert, beszerzi a szoftvert kompakt lemezeken. (Pl. kiíratja CD-re egy ismerősével, aki egy Internet-szolgáltatónál dolgozik, és le tudja tölteni azokat az ftp tükrökről.) Továbbá megegyezik egy Internet-szolgáltatóval az előfizetésről is.

2. Költségek becslése mintapélda alapján.

Erről szintén nehéz általánosságban nyilatkozni. Mint már említettem a szoftver beszerzési és használati költsége 0 Ft. A nagy ellenérv a TCO szokott lenni a szabadszoftverek ellen. Vagyis a termék egész használati élettartama alatti összes ráfordítás. Pl. az legyen a rendszergazda továbbképzése, az írott dokumentáció beszerzése.

Természetesen az ingyenes szoftverekhez terméktámogatás nem jár ingyen. Amennyiben szükségünk lenne telefonos vagy e-mail-es terméktámogatásra, akkor arra több cégnél is előfizethetünk. Pl. a http://www.linuxcare.com egy olyan cég, amely támogatást nyújt a különböző Linux rendszerekhez (Persze főleg angolul, magyarul nem). A kereskedelmi terjesztések többféle konstrukciót is nyújtanak, ha a dobozos (vagyis több ezer forintos) termékeiket vásároljuk meg. Ennek ellenére én ezt semmiképp se javaslom, hiszen ekkor épp az ingyenességről mondunk le.

Amint a licenszekből is kiolvashatjuk, a szoftverekhez semmilyen garancia nem jár, tehát nem vonható felelősségre senki, (csak a rendszergazda) ha valami nem úgy működik, ahogy azt szeretnénk.

A legköltségkímélőbb megoldás csakis az lehet, ha a rendszergazda több Linux-os levelező listát is olvas, és oda intézi kérdéseit. Sok "borzasztó" problémáról gyorsan kiderül, hogy sokan már szembesültek ilyen szituációval, és már kész megoldással tudnak nekünk szolgálni. Ezektől az önkéntesektől ne várjunk lehetetlent, ne követelőzzünk megoldásért, mert ezek az emberek csupán jóindulatból segítenek és azért, mert emlékeznek, hogy amikor ők kezdték, akkor nekik is segített valaki. Legyünk tehát kultúráltak és ne zaklassuk kis butaságainkkal állandóan csak egy személyt, hanem minél több emberrel ismerkedjünk meg. Hiszen 1-2 esetben mindenki szívesen segít, de már a 36. levél után úgy érezheti magát az illető, hogy rászálltak.

A rendszergazdának továbbá kötelessége követni a friss Linux-os híreket. Pl. http://www.linux.hu, http://slashdot.org, http://www.linux.org, http://www.linux.com, http:/freshmeat.net, http://linuxapps.com, stb. Figyeljük a biztonsággal foglalkozó helyeket, levelezőlistákat is, pl. security-l@sunserv.kfki.hu

Ha a rendszer mindig tartalmazza a biztonsági javításokat, és rendesen be van konfigurálva, akkor szinte rá se kell néznünk.

Az üzemeltetési költséghez tartozik a leállás is, hiszen a rendszergazdát elő kell keríteni, hogy indítsa újra a gépet és keresse meg a hiba okát.

"A költséghatékonysághoz tartozik a kiesett állásidő kérdése is. Linuxos gépek esetében ez minimálisra csökken, nem ritka az sem, ha egy gép 100-200 napot üzemel leállás nélkül. Például Donald Becker ,,A szövegszerkesztőtől a szuperszámítógépig'' címmel tartott előadást a jelenlegi Beowulf projektjéről, és beszélt a rendszerek stabilitásáról is. A legtöbb rendszere már 100 napja folyamatosan működik, de van olyan is, amelyhez 200 napja nem kellett hozzányúlni. Ez nem attól érdekes, hogy egy gép ennyi ideig bírja, hanem, hogy nagy számú (100-200) gép működik együtt ennyi ideje."⁸⁹

Véleményem szerint a TCO minimalizálható, ha a tervezéskor betartunk minden szabályt, és nem saját magunk ellen dolgozunk. A megvalósításnál természetesen nem szabad nagy kompromisszumokat kötni a terv ellenében, hiszen akkor felesleges volt a tervezési fázis. A "Jó lesz az, hidd el!" alapon végzett munka mindig félmunka.

Ha egy már meglévő gépre telepítjük a rendszert, akkor a hardver költsége is minimális lehet (egyéb kiegészítőkre mindig szükség lesz). Ha rászánunk egy kis pénzt, akkor igénytől függően összeállíthatunk pl. egy Celeron-os gépet 100-150 ezer Ft + ÁFÁ-ból. Egy komolyabb duál-PII-es gépet is ki lehet talán hozni 300 ezer Ft-ból. A fontos az, hogy viszonylag minőségi és elterjedt alkatrészekből építkezzünk, mert így sok fejfájástól kímélhetjük meg magunkat. Termékneveket nem akarok megemlíteni, többek között védjegyi okok miatt is - egyébként mindenkinek a maga ízlése szerint. Mindenki attól a cégtől vásárol, amely termékeivel jó tapasztalatai vannak. Sokat lehet vitatkozni, hogy ki mikor milyen egységgel hogyan járt, miközben a másik termék kitűnően működött, vica versa.

Konkrét árakat pedig azért is badarság lenne említenem, mert az már a jövő héten nem lenne igaz, nemhogy mikorra az olvasó ezt a könyvet a kezébe veszi.

3. Biztonság

Megfelelő rendszertervezéssel elejét lehet venni a legkülönfélébb támadásoknak. Ha betartjuk a II. Alapfogalmak / 8. Biztonsági alapok (hardver, szoftver), IV. Megvalósítás / 2. Finomítás fejezetekben leírt szabályokat, továbbá a következő tanácsokat is betartjuk és alkalmazzuk, akkor nagymértékben fokozhatjuk a rendszerünk betörés-biztosságát és helyes működését.

3.1 Milyen programok lehetnek / nem lehetnek egy Web-szerveren?

Egyes programokat / szolgáltatásokat egyáltalán nem tanácsos és felesleges egy éles Web-szerveren futtatni és / vagy tárolni, mert támadási felületet biztosíthatnak a behatolók számára. Bár egyazon szerveren rengeteg szolgáltatást tud nyújtani a Linux, igazából, biztonsági okokból egy külön erre a célra kijelölt gépet kell Web-szerverként üzemeltetnünk. A "mindent egybe" filozófiát pedig felejtsük el. Néhány fontos tanács:

• Ne legyen semmilyen fordító és fejlesztő eszköz / program. Ezek lehetőséget adnak a betörőnek, hogy trójai faló programokat fordítsanak a rendszeren.





• Ne legyenek NFS export-ok, NFS szerver. Az NFS-t No File Security-nek is szokták csúfolni. Rajta keresztül könnyen feltörhető a rendszer.





• Ne legyen NIS.⁹⁰





• Ha lehet ne legyen FTP szerver. Helyettesítsük scp-vel. Ha viszont lesz, akkor ne legyen anonymous ftp szolgáltatás. A felhasználók legyenek chroot-olva a saját home-könyvtárukba.





• Ne használjunk telnet szolgáltatást. Helyettesítsük pl. ssh-val. (lásd később)





• Ne fussanak az r* és RPC szolgáltatások (lásd később)





• Ne fusson semmiféle felesleges szerver, pl. ircd, talkd. Továbbá ne tartsunk veszélyes klienseket (irc, icq, stb.)





• Ne szolgáltassunk ki a felhasználókról információkat (fingerd, identd)





• A különlegesen fontos fájloknál állítsuk be az immutable bit-et.⁹¹





• Szigorú umask⁹² érték elhelyezése az /etc/profile-ban, és a felhasználók egyéni beállításaiban.





• A rendszergazda számára elhelyezhetünk 077-es umask-ot is, de ezt csak a rendszer készre-tétele után érdemes. Ekkor a jog a következő lesz: -rw------





• Lehetőség szerint csak eredeti Debian csomagokat használjunk, ha viszont fordítanunk kell, próbáljuk meg először a forráskódot a Debian tükörről leszedni. Ha onnan nem tudjuk, akkor a készítő hivatalos honlapjáról, vagy ftp helyéről töltsük le, esetleg a hivatalos magyar tükörről. Erre azért van szükség, mert egy ismeretlen helyről beszerzett bináris program vagy forráskód tartalmazhat kiskapukat - tehát lehet, hogy kompromittált. A kernel és a Debian csomagok és források MD5-ös igazolással érkeznek, mely alapján ellenőrizni lehet a fájl integritását. A fordítást mindig másik gépen végezzük.

Karbantartás során:

• Rendszeresen ellenőrizzük, hogy mely programok rendelkeznek SUID és vagy SGID bit-ekkel. Ezt megtehetjük a következő paranccsal:





        find / -type f \( -perm -04000 -o -perm -02000 \)

• Rendszeresen ellenőrizzük, hogy mely fájlok írhatóak mindenki által. Ezt megtehetjük a következő paranccsal:





        find / -perm -2 ! -type l -ls

• Rendszeresen ellenőrizzük, hogy mely fájloknak nincsen tulajdonosuk. Ez azokra a fájlokra is jellemző lehet, melyek betörés céljára vannak használva. . Ezt megtehetjük a következő paranccsal:





        find / -nouser -o -nogroup -print

• Keressük meg az .rhosts fájlokat. Ezek betöréshez könnyen felhasználhatóak ezért töröljük őket, ha nincs rájuk különösen indokolt szükség.

        find /home -name .rhosts -print

Ezeket a fenti kereséseket betéve egy shell-script-be és azt a cron időzítő segítségével mindennap lefuttatva, ennek kimenetét a /var/log-ban elhelyezve, vagy e-mailben elküldve automatizálhatjuk. Ezek a lépések elhagyhatóak, ha egy jól beállított tripwire programot működtetünk.

3.2 A partíciók megtervezése általánosan és a mintapéldához

Fontos egy éles rendszer esetében szétválasztani a különböző funkciót betöltő alkönyvtárakat különböző partíciókra és egyeseket csak olvasható módban használni. Ez nagyban növelheti a rendszer hitelességét⁹³, és a mentéseket is leegyszerűsítheti.

A mai kernelek már támogatják (a 2.2-es folttal, a 2.4 alapból) az LVM (Logical Volume Management, Logikai Kötetkezelés)-t. Ezzel a módszerrel különböző merevlemezekről vagy egyazon lemezről, de különböző helyekről fűzhetünk össze partíciókat egyetlen egységgé, melynek mérete ezért dinamikusan változtatható. Itt erre a módszerre nem térek ki, csupán a hagyományos utat tárgyalom. Az LVM-et csak haladóknak ajánlom.

A következő táblázat tartalmaz egy lehetséges kiosztást. Esetünkben egy egyszerű IDE vezérlős ATA merevlemezről van szó, mely az első (ide0) vezérlő "master" részére van csatlakoztatva. Ezeket az opciókat csak a rendszer készre-tétele után szabad beállítani. Ha be lett állítva, teszteljük a rendszer újraindítását, hogy mennyire fog zökkenőmentesen zajlani.

A rendszer indulásakor az inicializáló script automatikusan felfűzeti a mount programmal a /etc/fstab fájlban szereplő bejegyzéseket. Ez a program az adott partícióra vonatkozó paramétereket is az fstab-ból olvassa ki. Az opciók jelentése:⁹⁸

"A következő opciókat minden fájlrendszer esetén alkalmazhatjuk:

• async A fájlrendszer minden írási/olvasási művelete aszinkron módon megy végbe.⁹⁹





• atime Frissíti az inode¹⁰⁰-ok elérési ideit minden elérés esetén. (Alapértelmezett.)





• auto A fájlrendszer csatolható a -a opcióval.¹⁰¹





• defaults Az alapértelmezett opciókat használja. Ezek: rw, suid, dev, exec, auto, nouser, és async.





• dev Értelmezi a karakteres vagy blokkos speciális eszközfájlokat a fájlrendszeren.





• exec Megengedi a bináris fájlok futtatását.





• noatime Nem frissíti az inode-ok elérési ideit minden elérés esetén. (Ez hasznos lehet pl. a `news spool' gyorsabb elérésének biztosítására news szerverek esetén.)





• noauto Csak kifejezett parancsra csatolható, azaz pl. -a opcióval nem csatolódik.





• nodev Nem értelmezi a karakteres vagy blokkos speciális eszközfájlokat a fájlrendszeren.





• noexec Nem engedi meg a csatolt rendszeren található bináris fájlok futtatását. Ez pl. akkor hasznos, ha egy szerver más architektúrájú binárisokat is tartalmazó fájlrendszert használ, mint a sajátja.¹⁰²





• nosuid Nem engedélyezi a set-user-identifier (suid) és set-group-identifier (sgid) bitek használatát.¹⁰³





• nouser Megtiltja minden közönséges (nem root) felhasználónak a fájlrendszer csatolását. (Alapértelmezett.)





• remount Megkísérli egy már csatolt fájlrendszer újbóli csatolását. Ezt arra szokás használni, hogy más opciókkal csatoljuk újra a fájlrendszert, például egy korábban csak olvasható fájlrendszert írhatóvá tegyünk.





• ro Csak olvasható módon csatolja a fájlrendszert.





• rw Írható/olvasható módon csatolja a fájlrendszert.





• suid Engedélyezi a set-user-identifier (suid) és set-group-identifier (sgid) bitek használatát.





• sync A fájlrendszer írási és olvasási műveleteit szinkronizáltan végzi.





• user Megengedi minden közönséges (nem root) felhasználónak a fájlrendszer csatolását. Ez az opció bekapcsolja a noexec, nosuid, és nodev opciókat, hacsak nem a további opciók ezt felülbírálják. (Biztonsági okokból ezt csak nagyon átgondolt esetekben szabad megtenni.)"

Tehát azok az alkönyvtár-rendszerek, melyek elméletileg nem tartalmazhatnak futtatható fájlokat (/var /tmp /home /boot) ne is legyenek képesek futtatásra. Továbbá a megfelelő partíciókon ne lehessen eszközfájlokat létrehozni, és az eszközökhöz hozzáférni, továbbá ne lehessen tulajdonos-váltó programokat se indítani. Azok a partíciók, melyek nem szabad, hogy változzanak (csak a rendszergazda változtathatja meg őket), csak olvasható formában legyenek felfűzve. Egy további trükk lehet az is, ha a ro-nak szánt partíciókat egy iso9660 (CD image) formában készítjük el. Ekkor az esetleges betörő hiába szerez rendszergazdai jogköröket, nem fogja tudni újra felfűzetni ezeket a fájlrendszereket rw-ben, mert az isofs maga csak olvasható. Ez persze további bonyodalmakkal jár és kissé nehézkes a rendszer frissítése, lévén, hogy mindig egy új ISO-fájlt kell készíteni.

1. A /boot partíciót azért tesszük legelőre és külön, mert:
   
   

   • Így biztosan látni fogja a lilo¹⁰⁴.

   
   
   

   • Jobb, ha ro és senki nem nyúl bele, ugyanis a kernel sérülékeny pontja a rendszernek.

   
   
   

2. A második a swap partíció, mely virtuális memóriát képez a lemezen. Ezzel a fizikai RAM 2-3 szorosáig tudjuk optimálisan bővíteni a rendszert. Ha pl. 64 MB RAM van a gépben, akkor ajánlott 128 MB swap-ot alkalmazni. Természetesen terheléstől függően lehet, hogy egyáltalán nem, vagy csak kis mértékben lesz használva a swap. Ha 128 MB memóriánk van, nem biztos, hogy kell 256 MB swap. Teszteljük a rendszert. Egy swap partíció maximális mérete 2 GB, de lehet több ilyen partíció is. Akár több lemezen is. Azért érdemes előre tenni a swap partíciót, mert ha azt a rendszer sokat használja, akkor így jelentős sebesség növekedés érhető el azzal szemben, mint amikor az a lemez "végén" helyezkedik el.





3. A harmadik a gyökér fájlrendszer, mely a /bin, /lib, /sbin, /etc, /root, /dev, /mnt könyvtárakat tartalmazza. Ezek olyan fájlokat tartalmaznak, melyeket csak a rendszergazdának javasolt megváltoztatni. Ezért ha már működik a rendszer és mindent jól beállítottunk és leteszteltünk, tegyük írásvédetté a gyökér partíciót. Ahhoz, hogy ez problémamentesen sikerüljön, olvassuk el a IV. Megvalósítás / 2. Finomítás / 2.13 A "/etc/fstab" és az "init script"-ek beállítása című fejezetet.





4. A negyedik partíció egy "extended" vagyis kibővített partíció. Ez azért nincs feltüntetve a listán, mert ez tartalmazza a többi logikai partíciót. A logikai partíciók számozása mindig öttől kezdődik, akár van 2,3,4-es elsődleges partíció, akár nincs.





5. Az ötödik partíció az első logikai. Ide a /usr alkönyvtár tartozik, melyre a rendszer indításához és alapvető működéséhez nem szükséges programokat teszi a telepítő. Mivel egy rendszerbeállítás után ennek sem szabad változnia, ezért ezt is ro-ban használjuk. Ez mindaddig kis méretet igényel, amíg kevés funkciót teljesít a szerver. Ekkor akár 50MB-al is beéri. Ha sokfunkciós alkalmazás-szervert építünk, akkor felmehet akár 1-2GB-ra is a mérete.





6. A hatodik tartalmazza a /home könyvtárat, mely a valódi felhasználók könyvtárait és fájljait tárolja. Mivel ebben a rendszerben nem lesz sok felhasználó - hagyományos értelemben jobbára egy se - ezért ez lehet elég kicsi is. Igény szerint állítsuk be a méretét. A felhasználóknak biztonsági okokból ne engedélyezzük indítható fájlok futtatását, eszközfájlok létrehozását és setuid-al való kísérletezgetést se. A mérete az adott rendszertől, vagyis a felhasználók számától függ. Általában legyen minél nagyobb, ha sok a felhasználó és minél kisebb, ha nincsenek valódi felhasználók, csak rendszergazdák. Pl. legyen 500 MB.





7. A hetedik az átmeneti fájlokat tartalmazó partíció. Ennek a könyvtárnak ún. "sticky" vagyis kb. "ragadós" bit-je van. Ez azt jelenti, hogy az adott folyamat kapja meg a saját maga által létrehozott fájl a tulajdonjogát. Pl. ha egy lali nevű felhasználó által futtatott program létre hoz egy átmeneti fájlt, akkor annak a tulajdonosa a lali lesz. Ekkor ezzel a fájllal azt tesz, amit akar, de a többiek fájljait nem tudja piszkálni, esetleg olvasni se - ha megfelelő az umask értéke. Sok felhasználó és egyszerre futó folyamat esetén kevés lehet a 100 MB, ekkor növeljük meg igény szerint. Ha olyan programokat használunk, melyek extrém nagy fájlokkal dolgoznak (hang, videó), akkor elég hamar elfogyhat ez a hely.





8. A nyolcadik a /var könyvtár: ez alatt találhatóak az állandóan változó adatok, mint pl. a levelezés, a rendszernapló, a csomag-adatok, stb. Továbbá itt lesznek elhelyezve a mysql adatbázisok is, ezért kellő mennyiségű helyet kell biztosítani ezek számára. Ne felejtsük el később a /var/lib/mysql könyvtárt naponta menteni.





9. Itt van a Web-szerver szíve-lelke, a Web-tartalom. Ez a /var/www könyvtár a Web-szerver dokumentum-gyökere. Ennek mérete a Web-hely mérete szerint kell, hogy alakuljon.

3.3 A biztonsági mentés (backup) lehetőségei, módszerei és javasolt paraméterei

Ez szintén egy ritkán betartott szabály és fontos kérdés. Jó mentés nélkül a rendszer nem sokat ér, nem biztonságos. A mentési "politikát" szabályzatban kell rögzíteni, be kell tartani és tartatni az eredményes helyreállítás érdekében. A következőket kell meghatározni: "

• milyen célra





• milyen gyakorisággal





• milyen eszközzel





• mely fájlrendszereket kell lementeni

A mentés céljai lehetnek:

• Hardver - főként merevlemez - hiba miatti teljes összeomlás esetén a rendszer gyors visszatöltését biztosítani lehessen.





• Biztonsági tartalék - egy tiszta, idegen behatolók aknáitól mentes rendszer - gyanított, vagy tényleges betörés esetére.





• A betörés és károkozás történetének utólagos felderítéséhez.





• Felhasználók állományai, arra az esetre, ha letörlik, elvesztik, rosszul javítanak bele.





• Számlázási vagy bármilyen jogi vita esetére bizonyíték. "[12 p. 61]

Mentési eljárás típusok:

• Telepítés utáni mentés: ekkor még semmilyen felhasználói adat nincs fenn.





• Teljes mentés: az összes partíció mentése.





• Inkrementális (réteges) mentés. Csak az utolsó mentés után megváltozott fájlok kerülnek mentésre.

Azokat a partíciókat, melyek csak olvasható formában vannak, elég egyszer elmenteni (vagyis csak minden változtatás / frissítés után). A folyamatosan változó partíciókat gyors változások esetén érdemes akár naponta is elmenteni.

A mentéssel szembeni követelmények:

• Sokáig őrizze meg a média az adatot, nagyon hibatűrő média kell.





• Szabványos, kompatíbilis, sokáig fennmaradó technológia.





• Többször felhasználható, nagy kapacitású, tartós média





• Címkén fel legyen tüntetve a mentés dátuma, a gép neve, a mentési szint, ha több mentés is ráfér, akkor mind.

A média fizikai védelme: Mivel a mentés tartalmazza az összes bizalmas adatunkat is, ezért lehetőleg páncélszekrényben kell tárolni, hőtől, fénytől, víztől, párától, mágneses és elektromos tértől elzárva. Védeni kell lopás ellen (és) szállítás közben is.

Legegyszerűbb az, ha a gépben van egy CD-író, benne egy újraírható kompakt lemez és a mentés minden éjszaka megtörténik a rendszer időzítő naplójából (/etc/crontab). Ennek a megoldásnak a hátránya az, hogy ha teljes mentést kell végezni, akkor kicsi lehet a 650Mb-os tárterület, továbbá a CD-k cseréje nélkül mindig csak egy mentésünk lehet, ami nem tanácsos. Továbbá szükség van egy ugyanekkora átmeneti tárterületre az ISO image fájl elkészítéséhez, mely az írás előtt szükséges. Ez a megoldás viszonylag gyorsnak, és tartósnak mondható. Ma már költséghatékony is.

A másik egyszerű megoldás egy nagyteljesítményű és tárolókapacitású szalagos egység. Ezekből elég nagy a kínálat. 2GB-os méret alatt nem ajánlom, hogy egységet vásároljunk. Javasolt akkora kapacitású egységet vásárolni, hogy egy teljes mentés egyben ráférjen. Linux alatt elég jól használhatóak az Ftape jellegű meghajtók, melyek az alaplapi floppy vezérlőre csatlakoztathatóak. A szalagos egységek közül vannak párhuzamos portra kapcsolhatóak és SCSI-s felületűek is. Az utóbbiak elég drágák is, ui. a SCSI vezérlőt is meg kell venni. Cserébe viszont nagyobb biztonságot kapunk. Valamint nagyobb sebességet és kapacitást is.¹⁰⁵

A fájlokat általában tömörítve érdemes menteni. Vannak olyan szalagos egységek, melyek hardveres tömörítést alkalmaznak. A CD-RW esetében azonban nekünk kell gondoskodni szoftveres tömörítésről is. Így a kapacitás akár kétszeres is lehet.

A következő fő kérdés a mentés szoftverének kiválasztása. Vannak a rendszerhez járó általános archiváló programok, mint amilyen a tar és a cpio is. A dump program azonban fájlrendszer-szintű mentést készít.

" A dump abban különbözik ezektől¹⁰⁶, hogy a fájlrendszer tartalmát közvetlenül, nem a fájlrendszeren keresztül olvassa. Ezt speciálisan biztonsági mentések céljából írták, míg a tar és cpio programokat elsősorban archiválásra, de azért használhatók biztonsági mentésre is.¹⁰⁷

A fájlrendszer közvetlen olvasásának vannak előnyei. Lehetséges ilyenkor a fájlok visszaállítása időbélyegjeik átállítása nélkül; a tar és a cpio használata előtt viszont a fájlrendszert először csak olvashatóan kell csatlakoztatni (mount-olni). A fájlrendszer közvetlen olvasása hatékonyabb is, ha mindent le kell menteni, mert a legkevesebb fejmozgással megoldható. A legnagyobb hátránya az, hogy a mentési program ilyenkor a fájlrendszer típusához kötődik: pl. a Linux dump utasítása csak az ext2 fájlrendszerre működik. A dump továbbá közvetlenül támogatja a mentési szinteket míg a tar és a cpio esetén ezt egyéb eszközökkel kell megvalósítani."

Természetesen vannak a "fapados" dump helyett más mentési programok és eljárások is. Ezek egy része viszont kereskedelmi termék. A dump-nál a hangsúly az automatizálhatóságon és a távoli gépekre történő mentésen van és nem a színes grafikus felületen. Főleg szalagos egységekhez használható. Segítségért forduljunk a manuálhoz.

A Potato-ban több professzionális mentési programrendszer is található. Ezek főleg központi backup-szerverre dolgoznak és kliens-szerver rendszerűek. Az egyik ilyen program az afbackup. Nagy hangsúlyt helyeznek a biztonságra és a kliens azonosítására. A backup-szerverről is indítható a kliensről való mentés. Lehetőség van a tömörítésre, és a partíciók közvetlen mentésére is.

Először is olvassuk el a dokumentációt. Ez segít a rendszer megértésében. Ha nincs külön gépünk a mentésre, de a szervernek van szalagos egysége, akkor sincs baj. A mentő program szerver része foglalkozik a szalaggal, a kliens része pedig a fájlokkal. A program beállítása igen egyszerű: elvégezhető az /etc/afbackup alatt lévő fájlokon és egy automata script program segítségével is.

Mivel a mentés mindenkinél más típusú egységre történhet, ezért eltekintek a konfigurációs fájlok részletes bemutatásától.

Egy másik hasznos mentő program a Potato-ban az amanda. Ezt inkább csak külön szalag-szerverekhez ajánlják. Továbbá ott van még a kbackup, taper, tob melyeket főleg az egygépes mentésre terveztek. Mindenkinek ajánlom, hogy próbáljon ki többet is, majd az igényeinek megfelelőt válassza. Én a mintapéldában a kbackup-ot használom.

A CD-írós mentéshez a következő programokat ajánlom:

cdbackup: http://cdbackup.home.dhs.org

scdbackup: http://scdbackup.linuxbox.com

Továbbá szükségünk lehet a CD írásához a cdrecord és az mkisofs programokra. Egy backup programokat összefoglaló hely:

http://linuxberg.externet.hu/conhtml/adm_backup.html

3.4 Szoftveres UPS (szünetmentes tápegység) felügyelet soros porton keresztül

Ma már elképzelhetetlen egy szerver szünetmentes tápegység (UPS, Uninterruptible Power Supply) nélkül. Az újabb típusok alkalmasak kapcsolatot teremteni a szerverrel és hosszabb áramszünet esetén megkérni azt, hogy álljon le. Ez általában a szerver soros portján keresztül történik.

Fontos paraméterek:

• van-e a tápegységnek soros vagy más kapcsolati lehetősége a szerverhez





• támogatja-e a Debian-ban lévő UPS felügyeleti démonok egyike a tápot¹⁰⁸





• mekkora az áthidalási idő, a teljesítmény





• mekkora az akkumulátor újratöltődési ideje





• mennyi az akkumulátor élettartama





• milyen hosszú a garancia





• kapható-e alkatrész, új akkumulátor a táphoz





• van-e túláram és/vagy túlfeszültség-védelem





• mennyibe kerül

A lehetőségek szerint válasszunk olyat, aminek rövid az újratöltődési ideje, van benne védelem, és persze kompatíbilis a szoftverünkkel. Ne sajnáljuk rá a pénzt, ez egy fontos alkatrésze rendszerünknek. Olyan 40-50 ezer forintból már jó készüléket lehet venni. Ha a szerverünk a szolgáltatónál lesz, lehet, hogy ott biztosítanak neki tápegységet, bár annak hátránya az lehet, hogy nem kapcsolja le automatikusan a szerverünket.

A Debian-ban a következő szoftverek találhatóak:

• apcd: Az APC Smart UPS termékeihez.





• apcupsd: Az APC cég termékeihez készült, a táp jelzése esetén kikapcsolási folyamatot indít. Támogatja a BackUPS, BackUPS Pro, SmartUPS V/S, és SmartUPS(NET/RM) termékeket.





• bpowerd: A Best Patriot cég termékeit támogatja.





• genpower: a legtöbb RS-232-es eszközzel működik. Extra képességei: hálózati feszültség érzékelése, lemerült akku felismerése, soros kábel felismerése, az UPS inverterének kiiktatása. A Debian csomagban van egy extra kábelhez való vezérlő is, melyet "apc-pnp"-nek hívnak. Segítségével a fenti extrák kihasználhatóak a következő termékeknél: APC Back-UPS Pro, Smart-UPS, és Matrix-UPS rendszerek.





• upsd: képes a hálózaton keresztül is menedzselni a szerverek UPS-eit.





• powstatd (-crypt): könnyen konfigurálható, főleg dumb¹⁰⁹ jellegű UPS-ekhez. a következő termékeket támogatja: CyberPower PowerSL soro, CyberPower Power2000 1500VA, CyberPower Power99 325VA, 400VA, 500VA, 720VA, Néhány régebbi CyberPower 385VA, 450VA modell, TrippLite Internet Office 500 UPS, több régebbi APC termék. Ez a program arra is képes, hogy több gépet is lekapcsoljon, melyek egy tápegységről futnak.

Nem ajánlhatok a fentiek közül "legjobb" címen programot, mert nincs lehetőségem kipróbálni az összes tápegységet. Mindenki válassza ki a neki szimpatikusat, esetleg tegyen fel többet is és próbálja ki mind. Természetesen az itt felsorolt eszközökön kívül is léteznek olyanok, melyekhez írtak Linux-os vezérlőprogramot (pl. MGE). Ezt a gyártó Web-helyén megtudhatjuk.

Fontos, hogy ha lehet, úgy állítsuk be a felügyeleti szoftvert, hogy küldjön levelet minden áramkimaradásról a rendszergazdának és legalább egy helyi dolgozónak, aki el tudja rögtön hárítani a hibát, ha leállna a szerver.

Lényeges, hogy a szerver BIOS-át ATX-es ház esetén - ha lehet - úgy állítsuk be, hogy áramkimaradás után azonnal bekapcsoljon, amint újra van áram.

3.5 A szükséges felhasználók/csoportok és a lemezkvóta megtervezése

Mindenek előtt szükséges leszögezni, hogy csak azok a személyek jussanak felhasználói jogosultsághoz (UN*X user account-hoz) a szerveren, akiknek erre tényleg szüksége van. Egy felhasználói számlát többen ne használjanak.

A rendszergazdai jelszót kettőnél se több, se kevesebb ember ne tudhassa. Csak olyan ember ismerje a rendszergazdai jelszót, akiben a cégvezetés nagyon megbízik.

Mint már ahogyan a II. Alapfogalmak / 6. A Web-személyzet felépítése c. fejezetben felvázoltam, a gépen dolgozó emberek különböző funkciókat töltenek be, és más-más feladataik vannak. Ezért más-más hozzáférési jogosultság is szükséges számukra.

A fő rendszergazda kapja meg a root jogosultságot. Ezenkívül neki is létre kell hozni egy felhasználói számlát, mert úgy lesz a rendszer beállítva, hogy root-ként csak a konzolról lehessen bejelentkezni (vagyis pl. ssh-val sem). Ha már bejelentkezett a gazda, akkor - ha szüksége van rá - átléphet a su paranccsal root szerepkörbe. Ez azért is előnyös, mert így két jelszót is fel kell törni ahhoz, hogy valaki bejusson. Továbbá napi teendőjének nagy részét nem kell root-ként végeznie, így megkerülhet sok csapdát és véletlen törlést is az ember. Csak azokat a tevékenységeket végezzük root-ként, amit nem lehet user-ként megtenni.

A webgazda teszi fel és tartja karban az oldalakat. Ő a www-data csoport tagja. Amennyiben többen is végzik ezt a munkát, legyen e csoport tagjainak olyan umask érték beállítva, mely lehetővé teszi a csoport tagjai számára az írás/olvasást is. Ha beírjuk a következő parancsot: umask -S, akkor érthetőbb formában tudhatjuk meg a jelenleg érvényes umask értéket. Pl. u=rwx,g=rx,o=rx. Ha ezt be szeretnénk állítani u=rwx,g=rwx,o= -ra, akkor megtehetjük umask -S u=rwx,g=rwx,o= paranccsal. Figyelem! Az Apache program www-data jogokkal fut. Ha egy olyan script-et írunk, vagy lehetőséget hagyunk a Web oldalon vagy programokban, akkor az Apache-nak, rajta keresztül pedig a támadónak írási joga lesz a szerver tartalmára (vagyis a Web-oldalakra.) Ezért jobb, ha egy külön csoportot hozunk létre, pl. web-csop néven. Ebbe a csoportba tartozzanak azok a felhasználók, akik a Web-tartalmon módosíthatnak közvetlenül a szerveren. A másik megoldás, hogy pl. a fájlok a webgazda tulajdonában vannak, de a www-data csoport a csoportazonosítójuk.

Ideális esetben nincs sok változás és elég, ha csak a webgazda kezeli az oldalakat. Ha viszont több ember dolgozik a szerveren, és gyorsabban változik a tartalom, pl. a fejlesztés alatt, akkor a többi embernek is lehet adni felhasználói számlát a gépre. Ezek az emberek legyenek a web-csop tagjai. Az általuk feltett fájlok jogosultságaival nekik kell törődni.

Ha azt szeretnénk, hogy az Apache program beállításait is a webgazda kezelje, akkor adjuk át neki az /etc/apache-ssl/ könyvtárat és fájljait. Ezt megtehetjük így is: chown -R webgazda:webgazda /etc/apache-ssl

Azt is megtehetjük, hogy a fájlok a root tulajdonában maradnak, de a csoportját adjuk át a webgazdának, majd írási jogot kap a fájlokra a csoport.

Az ideális esetben van külön Web-fejlesztői gép. Ekkor így néz ki a felhasználók listája:

Ha nincs külön gép, akkor a fejlesztés is a szerveren zajlik. Ekkor:

Igény szerint vehetünk fel más felhasználókat is, például az adatbázis feltöltéséhez és karbantartásához. Ezek a felhasználók nem hozhatnak létre új táblákat, nem törölhetnek meglévőket, nem módosíthatják az adatbázis szerkezetét, csupán feltölthetik adatokkal azt. Külön jogosultságrendszerrel megadható az is, hogy melyik táblához ki és hogyan férhet hozzá. Fontos kiemelni, hogy a MySQL saját felhasználó és jelszó adatbázissal rendelkezik. Ezeket a jogosultságokat az adatbázis-rendszergazda tudja kezelni. Ahhoz, hogy valakinek hozzáférése legyen az adatbázishoz, nem kell, hogy UN*X számlája legyen a gépen. Erre csak akkor van szükség, ha az illetőnek be kell jelentkeznie a gépre, hogy egy adatbázis klienst használjon. Mivel a UN*X-os kliens eléggé fapados az átlagfelhasználónak, ezért kétlem, hogy erre egyáltalán szükség lenne. Egy jól megírt Web-alkalmazással lehet kezelni az adatbázist felhasználói oldalról.

A következő fontos kérdés a lemezkvóta. Ha csak egy-két embernek van joga belépni a szerverre, akkor általában felesleges korlátozni az egy felhasználó által maximálisan felhasználható helyet. Ha azonban több felhasználó is helyet kap a /home könyvtárban, akkor már hasznos lehet a korlátozás. Ha egy felhasználó esetleg teletömné a lemezt, pl. az mp3 fájljaival, akkor a többiek számára nem maradna szabad hely a hasznos munkához. Az, hogy kit mennyire korlátozunk teljesen személyre szabható. Nem csak egyes felhasználókat, hanem csoportokat is szabályozhatunk. Minden olyan partíciót, ahova az átlagfelhasználónak írási joga van, érdemes kvótákkal ellátni. Esetünkben ez a /home, /tmp és a /var/www (a Web-csoport számára). Mivel az utóbbit valószínűleg csak munkára használja az ember, nem biztos, hogy korlátozni kell. A példában csak a /home partíciót korlátozom.

A kvóta két részből áll. Az első a soft limit, vagyis az a határ, melyet elméletileg szeretnénk, hogy betartsanak. A soft limit-et át lehet adott ideig lépni (grace period - türelmi idő), egészen a hard limit eléréséig. Ekkor új fájlokat a felhasználó már nem írhat a lemezre, az írni kívánt adatok elvesz(het)nek. Amint letelik a türelmi idő (általában 1 hét), a soft limit hard limit-té válik. Ilyenkor a felhasználónak le kell törölnie néhány fájlt, hogy visszatérhessen a felső határ alá.

Korlátozni a lefoglalt blokkokat és az inode-okat is lehet. A másodikra azért lehet szükség, mert egy rosszindulatú felhasználó sok rövid (pl. 0 bájtos) fájlt készíthet, mellyel lefoglalhatja az összes szabad inode-ot. Ekkor - bár a lemez nem telített - mégsem tudunk rá írni.

Az egyes felhasználók lemezkvóta-beállításait a root szabályozhatja az edquota -u fnév paranccsal. Egyes csoportok kvótái is szabályozhatóak: edquota -g csnév

Minden felhasználó ellenőrizheti a kvótáinak állását a quota paranccsal. A rendszergazda életét megkönnyíti a repquota parancs, mely egy adott partíció kvótáinak állásáról készít jelentést. A quotatstats program egy gyors statisztikát készít számunkra. A quotacheck leellenőrzi induláskor a kvótatáblázatokat. A quotaon és quotaoff parancsokkal lehet ki és bekapcsolni egy adott fájlrendszer kvóta-ellenőrzését. Bővebb információkért forduljunk a manuál oldalakhoz és a dokumentációhoz.

Példámban az alsó határt (soft limit) 20 megabájtban a felsőt (hard limit) pedig 40-ben jelölöm meg.