www.pingvinpasztor.hu

Először pár szót arról, hogy MIRőL NEM SZóL ez az anyag.

Nem akarok a Debian telepítésének menetéről mesélni, feltételezem, hogy aki ebből az anyagból akar profitálni, az már túljutott a telepítés nehézségein, illetve elérhetőek az Interneten kifejezetten a Debian telepítéséről szóló anyagok.

Nem írok részletesen arról, hogy egy-egy szolgáltatásra miért is van szükség a tervezett hálózatban, illetve nem szeretnék az ezekhez kapcsolódó elmélettel sem untatni senkit (bár valamennyit muszáj volt megemlítenem) - akit érdekel, az rengeteg jó dokumentációt találhat az Interneten.

Nem lesz szó ,,tuningolásról'', az egyes szolgáltatások memóriabeállításairól. Mégpedig azért nem, mert ezen opciók nagyon sok mindentől függenek, szinte lehetetlen megoldást mondani az egyes opciók értékére a körülmények pontos ismerete nélkül. Az egy gépen futó szolgáltatások, a sávszélesség, a felhasználók száma, a gépben lévő memória mennyisége - mind-mind olyan tényező1.1, amely az egyes szolgáltatások beállítását befolyásolja.

És most nézzük végre azt, hogy MIRőL SZóL a könyv. Kiválasztottam egy számomra szimpatikus hálózatot (egy C osztályút, a 192.168.10.0 címűt), és ebben a hálózatban szeretnék különböző szolgáltatásokat beüzemelni. Az üzembeállításhoz szükséges feladatok leírása ezen anyag egyik célja.

A szerverek Linuxot fognak futtatni, míg a munkaállomások windowsos gépek lesznek1.2. Lehetséges, hogy egyszer az anyag el fogja érni azt a szintet, amikor linuxos munkaállomások hálózatba állításáról is szót fog ejteni, de ez egyelőre csak nagyon távlati terv.

Nem kötelező minden - az anyagban szereplő - szolgáltatást üzembe helyezni a saját hálózatunkban. Azért ,,zsúfoltam'' bele talán feleslegesnek tűnő szolgáltatásokat (például másodlagos dns szerver), hogy a beállításával kapcsolatos dolgokat be tudjam mutatni.

A fejezetek sorrendje nem az elkészítés sorrendjét határozza meg (bár van olyan, amit csak meghatározott sorrendben lehet végrehajtani, például tanúsítvány generálása előtt nem lehet a tanúsítványt használó LDAP szervert üzembe helyezni). Egyszerűbbnek tűnt, ha minden szolgáltatásról külön fejezet szól (még akkor is, ha maga a szolgáltatás több gépet is érint - ekkor külön alfejezetben szólok a különböző gépek konfigurációs igényeiről). De nézzük meg, hogy milyen szolgáltatásokat terveztem beüzemelni a hálózatban (picit részletesebb magyarázatot az egyes fejezetek elején találhat a Tisztelt Olvasó az egyes szolgáltatások szükségességéről):

* DNS (elsődleges és másodlagos);

* DHCP (egyes gépekhez fixen hozzárendelt IP címek);

* SMTP (a belső hálózat levelezése, valamint az Internet felé irányuló levélforgalom);

* IMAPS (titkosított kapcsolaton keresztüli levélkezelés, miközben a levelek a szerveren tárolódnak);

* proxy (sávszélességünk védelme és egyéb megfontolások);

* fájltárolás (fájlok tárolása a szerveren);

* központi felhasználókezelés (egy jelszót minden szolgáltatáshoz, ,,single sign on'');

* naplózás (központi logszerver, logelemzések);

* backup (ha minden a szervereken van, akkor érdemes menteni);

* pontos idő (például a titkosításokhoz szükséges, hogy azonosan járjanak a szerverek órái, de a logokban való keresgélést is megkönnyíti, ha az összes gép órája azonosan jár);

* belső webszerver (például nyilvános adatoknak);

* tűzfal (védjük meg, amit összeraktunk).

A gépek nevei és IP címei (a belső hálózatban példaként az akarmi.intra tartománynevet fogom használni) a következők (ezeket az adatokat fogom felhasználni az egész anyagban, ezeknek megfelelően készülnek majd el a konfigurációs állományok):

* a belső weboldalakat tároló szerver - intraweb, 192.168.10.247;

* a mentéseket végző szerver - backup, 192.168.10.248;

* a logszerver - syslog, 192.168.10.249;

* a fájlszerver - samba, 192.168.10.250;

* a proxyszerver - proxy, 192.168.10.251;

* a levelezőszerver - mail, 192.168.10.252;

* a DNS-szerver - dns, 192.168.10.253;

* a tűzfal belső hálózat felé néző lába - fw, 192.168.10.254.

Nem lehet megszabni, hogy milyen szolgáltatásokat kell egy gépre összerakni, és melyeket muszáj más gépekre telepíteni. Ebben a kérdésben is csak az általam követett elveket tudom elmondani (plusz még néhány olyan dolgot, amelyet fontosnak tartok kiemelni):

* A DNS és DHCP szolgáltatást azért szoktam egy gépre tenni, mert hasonló adatokra van szükségük, és egyszerűbb szkriptből generálni a mindkét szolgáltatáshoz szükséges állományokat. Ez pedig nehézkes lenne (persze nem megoldhatatlan), ha külön gépen lennének. Természetesen lehetséges külön gépen futtatni ezeket az alkalmazásokat, és például cvs-ből venni a konfigurációs állományokat.

* A DNS-ben (és egyúttal a DHCP-ben is) érdemes valamilyen rendszer szerint elkülöníteni pár dolgot. A szerverek, a hálózati nyomtatók, az aktív eszközök és a felhasználói gépek csoportosítását tartom én célszerűnek. Egy lehetséges megoldás netmaszk határokon ,,vágni'', ez a későbbi esetleges fizikai szétválasztást is egyszerűvé teszi. Természetesen bármilyen más felosztás is megoldást jelenthet, sőt, ilyen jellegű felosztás nélkül is működőképes a hálózat. Hasznos olvasmányok a döntéshez az rfc1519.txt (http://www.ietf.org/rfc/rfc1519.txt) és az rfc1219.txt (http://www.ietf.org/rfc/rfc1219.txt).

* Az IMAP-on történő levelezés meglehetősen sok feladatot ad a diszk-alrendszernek (sok egyidejű felhasználó esetén), és a hálózati forgalma is nagy tud lenni. Emiatt nem célszerű hasonlóan nagy hálózati forgalmat bonyolító szolgáltatásokkal egy gépre telepíteni, amilyen például a samba és a squid.

* A proxy (squid) is komolyan képes igénybevenni a diszk-alrendszert, emiatt célszerű önmagában futtatni, illetve olyan diszkeket (vagy diszkelrendezést) választani, amelyek képesek megfelelni ennek a terhelésnek. A diszkrendszer terhelését befolyásolja például a letöltésre használható sávszélesség is. Még a fájlrendszer kiválasztására is ügyelnünk kell, sőt, a mountolás opcióival is lehetőségünk nyílik gyorsítani a rendszert (például a noatime opcióval).

* Az IMAP és az SMTP szolgáltatás egy gépen történő futtatása ésszerűnek tűnik, hiszen a levelek kézbesítéséhez szükség van egy MTA-ra (SMTP szolgáltatásra).

* NTP szolgáltatást szoktam a tűzfalra is telepíteni, hogy a belső szervereknek ne az Internetre kelljen menniük a pontos időért. Viszont a belső hálózat klienseit nem szoktam a tűzfalhoz odaengedni, ezért a belső hálózaton is létre szoktam hozni NTP szervert (vagy szervereket), amelyek közvetlenül a tűzfalhoz szinkronizálják az óráikat, és szolgáltatnak a kliensek felé. Amennyiben nem áll rendelkezésünkre egy gép, amely a belső ntp szerver lehetne, akkor természetesen a kliensek szinkronizálhatnak a tűzfalon futó ntp szerverhez.

* Ugyanez a helyzet a DNS szolgáltatással is. A tűzfalra is telepítek, hogy a belső DNS szerver ne az Interneten lévő szerverekkel beszéljen. Ily módon csak a tűzfallal kell beszélnie. De a tűzfal is csak a belső hálózat dedikált DNS szervereivel kommunikál, a kliensek nem érhetik el a tűzfalon futó DNS szolgáltatást közvetlenül. Amennyiben nem áll rendelkezésünkre egy külön gép, amely a belső DNS szerver lehetne, akkor természetesen a klienseknek is el kell érniük a tűzfalon futó DNS szervert.

* A központi logszerverre nem igazán érdemes mindenki számára elérhető szolgáltatásokat telepíteni, nehogy a felhasználók elfoglalják a logolás számára létfontosságú sávszélességet. Célszerű a logelemző programokat is ezen a gépen futtatni, nem pedig a különálló szervereken, bár vigyáznunk kell, hogy az elemző programok ne terheljék le annyira a gépet, hogy az ne legyen képes mással foglalkozni.

* A mentéseket végző (és tároló) gépre lehetőség szerint semmilyen kívülről elérhető szolgáltatást nem szabad rakni, hiszen (valószínűleg) a lehető legtöbb érzékeny adatot ez a szerver tárolja.

* Az rsync csomag sokszor a segítségünkre lehet, érdemes telepíteni. Alapbeállításban nem fut démonként, tehát nem nyújt lehetőséget a gép kívülről történő elérésére. Jellemzően ssh csatornán keresztül használjuk.

A könyv a következő oldalon olvasható:
http://www.mithrandir.hu/doc/book/index.html