Az előzőekben lépésről lépésre bemutattam egy komplett teszt webszerver összeállítását, ami már így önmagában is használható, de egyelőre még nem kényelmes a kezelése. Az első lépés a nagyobb kényelem és a virtuális gép hordozhatósága felé, az egyszerű "hosts" fájlos domain kezelés leváltása a BIND9 névszerverre, ami egy rugalmasabb megoldást tesz lehetővé.
A névszerver használatával nem kell minden gazda gépen újra felsorolni az összes IP-domain párt, csak a névszerver IP címét kell felvenni az adott hálózat névszervereként. Lehetne ez egy távoli gép is, de ha nem több gépből áll a tesztkörnyezetünk, akár önmaga is lehet.
Ebben a fejezetben bemutatom BIND9 névszerver alapszintű konfigurációját és a gazda géppel való együttműködését.
Tartalomjegyzék
- Tartalomjegyzék
- Előkészületek
- Miért névszerver?
- Beállítások
- Elv
- Zóna definíció
- vm1 zóna
- a24.vm1 zóna
- a22.vm1 zóna
- 192.168.56.* IP-k domainjei (Reverse lookup)
- Névszerver hozzárendelése a gépekhez
- Összefoglalás
- Források
Előkészületek
Ahogy mindig, most is szükség lesz root jogra a sudo su vagy su - root parancsokkal.
A Debian 6 telepítésekor javasoltam a DNS kiszolgáló telepítését. Most pontosan erre lesz szükség. Ha valamiért mégsem volna fent, akkor azt a következő módon lehet telepíteni Deban 6 -ban és egyéb Debian alapú disztribúciókban:
Miért névszerver?
Jelenleg az én hosts fájlom így néz ki:
192.168.56.2 a24.vm1
192.168.56.2 www.a24.vm1
192.168.56.2 p5414.a24.vm1
192.168.56.2 www.p5414.a24.vm1
192.168.56.2 p5324.a24.vm1
192.168.56.2 www.p5324.a24.vm1
192.168.56.2 p5217.a24.vm1
192.168.56.2 www.p5217.a24.vm1
192.168.56.3 a22.vm1
192.168.56.3 www.a22.vm1
192.168.56.3 p5414.a22.vm1
192.168.56.3 www.p5414.a22.vm1
192.168.56.3 p5324.a22.vm1
192.168.56.3 www.p5324.a22.vm1
192.168.56.3 p5217.a22.vm1
192.168.56.3 www.p5217.a22.vm1
#mysql
192.168.56.2 m56.vm1
192.168.56.3 m51.vm1
Ezeket a bejegyzéseket a gazda gépen és a virtuális gépen is meg kell adni, hogy mindkét gép ismerje a címeket. Ha új domaint szeretnék beállítani, akkor azt mindkét fájlban meg kell tennem, különben amikor szükség lesz a szerveren két virtuális hoszt kommunikációjára, akkor ér a meglepetés, hogy nem lehetséges.
Két helyen kell vezetni ugyanazt és el is írhatom. Majd kereshetem, miért megy egyik helyen a program és a másikon miért nem.
Ha később kinövi a MySQL szerver a virtuális gépet, vagy csak más miatt támad kedvem áthelyezni, megint mindkét helyen állíthatom át, hogy a webszerver is megtalálja és a gazda gépből is tudjak valamilyen programmal csatlakozni.
Ez kényelmesnek biztosan nem mondható, és az is látható, hogy az összesen két IP címet is sokszor meg kellett adni. A névszerver ezt is leegyszerűsíti.
Végül még egy érv, hogy a hosts fájlokkal nincs lehetőség arra, hogy egy bizonyos domain összes aldomainjét átirányítsuk a fődomainre és így akár PHP-ból kezelhető le, hogy melyik aldomainen mi töltődjön be. Úgy, mint a blogoldalakon, ahol egy regisztrációval aldomaint is kap a felhasználó.
Beállítások
Elv
Léteznek különböző zónák, amikben a szabályokat definiálni lehet. Például ".hu", ".com" vagy "sajatdoldal.hu" is lehet zóna. Minden zónának van egy felelőse, aki a beletartozó domaineket, aldomaineket meghatározhatja. Megmondhatja, melyik domainhez melyik IP tartozik és IP alapján a hozzá tartozó domaint vagy domaineket. Ezt az oda-vissza megfeleltetést fogjuk most megírni a "vm1." zónához.
A "vm1" a virtuális gépen használt legfelső szintű domain (TLD). Ilyen nem létezik a világhálón és nem is valószínű, hogy fog. Így nem lesz ütközés. De a TLD-k listáját az ICANN oldalán is le lehet ellenőrizni.
A Bind9 konfigurációs fájljai az "/etc/bind/" mappában találhatók. Sokukat nem ajánlatos változtatni. De új fájlokat létre lehet és kell is hozni. Lehetne a fő könyvtárba is, de én praktikusabbnak tartom a saját kontárkodásaimat egy külön "myzones" mappába tenni.
Először a saját zónákat kell felsorolni a hozzájuk tartozó konfigurációs fájlokkal és a zónák típusával (minimum), majd magát a zónafájlt kell kifejteni. A végén pedig meg kell mondani a szervernek is, hogy ő bizony névszerver is. Tehát kérdezze meg a domainekről a telepített bind-ot is. Ezt persze ugyanígy meg kell tenni minden olyan gépen, amelyikről el szeretnénk érni a szerver domainjeit.
Zóna definíció
A "named.conf.local" fájlban csak megjegyzések vannak. Ide nyugodtan beírhatjuk a zónalistát. Most a hosszú szövegelés helyett jobbnak látom egyből a fájlt mutatni a módosítás után:
type master;
file "/etc/bind/myzones/db.vm1";
};
zone "a22.vm1" {
type master;
file "/etc/bind/myzones/db.a22.vm1";
};
zone "a24.vm1" {
type master;
file "/etc/bind/myzones/db.a24.vm1";
};
zone "56.168.192.in-addr.arpa" {
type master;
file "/etc/bind/myzones/db.192.168.56";
};
A zone kulcsszó után a zóna nevét kell írni. A "type"-pal megmondjuk, hogy miféle zóna ez. A master tartalmazza közvetlenül a megfeleltetéseket a "file" után írt fájlban. A zóna tulajdonságait kapcsos zárójelek közé írjuk és nem szabad elfelejteni a bezárás után a pontosvesszőt sem. A fájlok nevei praktikusan lehetnek a domainek. A már meglévő fájlok alapján én "db"-vel kezdtem a neveket.
Látható, hogy van egy kakukktojás zóna, aminek a neve egy fordított IP cím részlete és az "in-addr.arpa" végződés. Így jelezzük, hogy itt az IP címekhez tartozó domaineket soroljuk fel (Reverse lookup zóna). Ez alapján lehet egy IP címből visszakeresni, hogy melyik domain tartozik hozzá. De nincs vész. Nem kell az összeset felsorolni. Elég az elsődleges domaint.
A "file" utáni útvonal lehet abszolút, vagy relatív a "directory" opcióhoz képest. Ezt az opciót a "named.conf.options" fájlban találjuk és alapértelmezetten "/var/cache/bind".
vm1 zóna
Ebben a zónafájlban (myzones/db.vm1) már tényleg a domainek leírása következik.
; vm1
;
$TTL 604800
@ SOA ns1.vm1. root.vm1. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
ns1 A 192.168.56.2
ns2 A 192.168.56.3
@ NS ns1
@ NS ns2
m56 CNAME ns1
m51 CNAME ns2
Ez annyit tesz lényegében, hogy elérhetővé teszi a következő domaineket:
- ns1.vm1
- ns2.vm1
- m56.vm1
- m51.vm1
Az ns1 és ns2 valójában a névszerverek lennének. Egyetlen virtuális gépen dolgozom, tehát önmagát kétszer megadni nem sok értelme van. Sok domain esetén viszont csak egyszer kell megadni az IP-t és a többinél csak a beszédes ns1 és ns2-re hivatkozva lehet további álneveket beállítani ugyanahhoz az IP-hez.
Az elejére beírtam megjegyzésbe a zóna nevét. Itt a pontosvessző a megjegyzés sorának jele.
A $TTL elvileg kötelező Bind9-ben, A domainek működését mégsem befolyásolta a törlése. Utána a domainek cache-elési idejét írjuk másodpercben. Ennek lejárata után a klienseknek el kellene felejteni a korábban mentett IP-domain párt és újra meg kell kérdeznie a névszervert.
A kukac jel itt a zóna nevét helyettesíti. A SOA rekord így az adott zónára vonatkozik. A SOA után sorban az elsődleges névszerver címét és a zóna felelősének email címét kell írni. Mivel a kukac jelet oda nem írhatjuk, azt is ponttal kell helyettesíteni. Ha az email cím kukac előtti része is tartalmazna pontot, akkor azt "\." -ként kell írni. Esetünkben ezeknek sok jelentősége nincsen. Az elsődleges névszervernek is inkább éles környezetben, ahol van master és slave névszerver.
Az emailcímet több szám követi másodpercben, vagy az újabb Bind verziókban már emberbarátibb formában, mint 1w, ami az 1 hetet jelenti, vagy 3d, ami a 3 napot. És így tovább. Ezeket a számokat egy sorba is lehetne írni. Ha több sorba akarjuk írni, akkor zárójelet kell használni. Ahogy az a példában is van. Az értékek pontos jelentéséről a http://www.szabilinux.hu/dns/#N16 oldalon lehet olvasni. Erre nem térnék ki, mert ezeknek is kevés jelentősége van a virtuális tesztkörnyezetünknél.
Ami lényeg, az az "A" rekord. Minden domainhez rendelni kell valamilyen módon egy IP címet. Az egyik módja az "A" rekord használata. Az A betű előtt a domain neve található. Tőle jobbra pedig az IP címe. A domaint viszont lehet relatívan és abszolútan megadni. Itt a zóna a viszonyítási alap. Tehát az ns1 valójában ns1+zóna neveként, azaz "ns1.vm1." -ként értelmezendő. A pontot szándékosan írtam a végére. Abszolút hivatkozásnál kötelező kiírni a pontot a domain végére. Bár ezt a zóna nevénél nem volt kötelező az előző konfigurációs fájlban.
A névszervereknek elég lesz ebben a zónában IP-t adni. Az alárendelt zónák ismerni fogják már.
Azt, hogy ez a domain egy névszerver domainje, úgy adhatjuk meg, hogy az "NS" rekordot használjuk. Ilyenkor balra a zóna neve kell, aminek a névszervere lesz az NS jobb oldalán levő domainhez tartozó szerver. A kukac karakter itt is használható. És a zónához viszonyított relatív domainnév is használható jobb oldalt.
A domain készítésének másik módja a "CNAME" rekord. Ebben az esetben baloldalt az "A" rekordhoz hasonlóan az új domain áll. Jobb oldalt viszont egy másik domain, amihez tartozó IP címhez kell kötni az újat is. Egy eleve álnévhez is lehet ugyanígy újabb álnevet rendelni, de kerülendő túlzásba esni vele. Olyankor a névszerver előbb megtalálná a kért domaint, ami egy álnév, így tovább keresné az eredetin keresztül az IP-t. Ha az is álnév, akkor ezt addig végzi, míg el nem jut az IP-hez. Felesleges körök. De lehet helye olykor ennek is.
A példában így a névszervereken kívül két új domain jött létre. Ez a két MySQL domainje. Az a22.vm1 és a24.vm1 külön zónafájlt kaptak, így azoknak ott adunk IP-t.
a24.vm1 zóna
A fájl a myzones/db.a24.vm1, a tartalma pedig a következő:
; a24.vm1.
;
$TTL 604800
@ SOA ns1.vm1. root.vm1. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ A 192.168.56.2
@ NS ns1.vm1.
@ NS ns2.vm1.
www CNAME @
p5414 CNAME @
www.p5414 CNAME @
p5324 CNAME @
www.p5324 CNAME @
p5217 CNAME @
www.p5217 CNAME @
Nincs semmi új már benne. A kukacot használom ezerrel. Az a24.vm1 alá tartozó aldomaineket sorolom fel relatív hivatkozással. Megkapta a zóna a két névszerverét és kapott egy IP-t. Mivel a hosts fájlos megoldásban is minden domain működött www előtaggal is, így azt a verziót is definiáltam.
Ha valakinek eszébe jutna a www utáni ponthoz igazítani a www nélküli domaineket, ne tegye! A behúzásnak is szerepe van. Vannak olyan esetek, amikor két egymás utáni sornál csak az elsőben szerepel a domain. A második szintén hozzá tartozik, így azt elhagyva eleve beljebb kezdődik a többi rész. Ez számunkra most nem lényeges.
A "CNAME" és "A" baloldalán a domain legbaloldalibb részét helyettesíthetjük csillag karakterrel is. Ilyenkor az összes aldomainre érvényes lesz a jobb oldalon álló IP cím vagy domainnév. Ez használható akkor, ha egy domainen levő weboldal az összes aldomainjén megjelentő tartalmat maga kezeli programkódból. Ekkor még a virtuális hoszton kell ServerAlias-ként felvenni a címet szintén a csillagos helyettesítést használva.
a22.vm1 zóna
A myzones/db.a22.vm1 fájl tartalma gyakorlatilag csak az IP-ben és a megjegyzésben tér el:
; a22.vm1.
;
$TTL 604800
@ SOA ns1.vm1. root.vm1. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ A 192.168.56.3
@ NS ns1.vm1.
@ NS ns2.vm1.
www CNAME @
p5414 CNAME @
www.p5414 CNAME @
p5324 CNAME @
www.p5324 CNAME @
p5217 CNAME @
www.p5217 CNAME @
Ezt már tényleg nem kell magyaráznom, azt hiszem. Ezzel majdnem végeztünk az összerendelésekkel. De vissza van még a "Reverse lookup" zóna.
192.168.56.* IP-k domainjei
Most jön az a rész, amikor az IP-ket kell felsorolni. A fájl a myzones/db.192.168.56, a tartalma pedig:
; 192.168.56.*
;
$TTL 604800
@ SOA ns1.vm1. root.vm1. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ NS ns1.vm1.
2 PTR a24.vm1.
3 PTR a22.vm1.
Megfigyelhető, hogy itt is van egy névszerver (kettő is lehetne) és nincs megadva a teljes IP cím. Csak az a része, ami nem került bele a zóna nevébe. Ezt is lehet relatívan írni. Így csak a 2-es és a 3-as áll a "PTR" előtt, aminek jobb oldalán a hozzá tartozó domain. Azt viszont nem relatívan adjuk meg, mivel az IP a viszonyítási alap.
Ha a névszerver újraindítása után nincs hiba, akkor készen is vagyunk.
/etc/init.d/bind9 restart
Névszerver hozzárendelése a gépekhez
Eddig felépítettük magát a címeket tartalmazó névszervert. De azt még maga a szervergép sem használja. Pláne nem a kliens. A dolog nem olyan egyszerű, de nem is vészesen nehéz, ha az ember egyszer rájön.
Az alap probléma a címfeloldás működése. Azaz ha van is 3 névszerver megadva, csak az első olyan névszerver tér vissza a válasszal, amelyik elérhető. Függetlenül attól, hogy ismerte-e a címet vagy sem.
Olyan esetben, ha nincsen külön másik helyi hálózat, intranet, a saját névszerverünk címét elég lenne megadni. És ha ő nem tudja a választ, megkérdezi a felsőbb zónákat. Azok a zónák viszont nem fogják ismerni a saját privát hálózatunkat. Tehát rá kell bírni a rendszerünket, hogy párhuzamosan több névszervert is kérdezzenek meg, ha netán az egyik nem ismerné a címet.
Windows 7-ben
Windows 7-ben könnyű dolgunk van. Ugyanis ha létrehozunk egy új hálózati kapcsolatot, ott megadhatjuk a privát névszervert is. Esetünkben a virtuális gép létrehozásakor a VirtualBox létrehozott egy ilyen kapcsolatot. Nincs más dolgunk, mint a
Start menü » Control Panel » Network and Sharing Center
Magyarul: Start menü » Vezérlőpult » Hálózati és megosztási központ
menübe lépni, majd jobb oldalt kiválasztani a kapcsolatot. A leírásaimat követő olvasóknak ez a "VirtualBox Host-Only Network". Rákattintva felugrik az ablak, ahol alul a "Properties" (Tulajdonságok) gombra kell kattintani. Ott megint felugrik egy ablak, ahol pedig ki kell választani az "Internet Protokol Version 4" (A TCP/IP protokoll 4-es verziója) elemet. Újra "Properties" (Tulajdonságok) gomb, ami után megadható az "Preferred" (elsődleges) és "Alternate" (másodlagos) névkiszolgáló. Ha háromra lenne szükség, akkor az "Advenced" (Speciális) gombra kattintva a "DNS" fülön további szerverek adhatók meg. Most viszont erre nincs szükség.
Tehát adjuk meg elsődleges névkiszolgálónak a "192.168.56.2" -es IP-t! Vagy aki más IP-t rendelt a szervergéphez, az természetesen azt az IP-t kell, hogy megadja.
Debian 6-ban
A Debian 6 nálam csak a szerver. De a bind-ot feltelepítve a kliens gépen is elvégezhetők ezek a beállítások. Ott persze nem kell a domaineket definiálni.
A "named.conf.options" fájlban az "options" blokkban alapértelmezetten megjegyzésbe van téve a "forwarders" blokk.
//
//};
Ide írjuk be a további privát hálózatok névszervereinek IP címeit. Például:
10.1.0.1;
10.1.0.2;
};
A bind szervert újraindítva már a nem ismert címeket a felsorolt IP-ktől is megkérdezi. Viszont van még egy probléma. A /etc/resolv.conf fájl. Ebben ugyanis bekerülnek névszerverek címei, ha dhcp szerver osztja ki az IP-ket. Az eth0 interfész dhcp-n keresztül működik. És olyan sorrendben másolja az IP-ket, ahogy jónak látja. Tehát ha a privát névszerver címe a lista végére kerül, nem fog működni a saját domainünk a szervergépről nézve.
De ha az elejére, akkor a többi belső hálózathoz tartozó domainek nem fognak működni. Utasítani kell a dhcp klienst, hogy ne másolja át ezeket a címeket, csak a saját szerver névszerverének címét, ami a forwarders blokkban hivatkozik a többire. Ennek mikéntjéről már írtam a Debian 6 hálózati beállítások VirtualBox 4.2-ben fejezetben.
Tehát a supersede utasítás után kell megadni a névszerver címét. Ha meg akarunk spórolni egy kis munkát az IP címek változtatásakor, akkor itt a lokális IP-t, a 127.0.0.1 -et adjuk meg. Ez úgyis csak helyileg vonatkozik a szerverre. Ami a helyileg telepített névszerver által visszaadja a címeket.
Tehát ez kerüljön be a /etc/dhcp/dhclient.conf fájlba a "request" sora elé például:
supersede domain-name vm1;
A domain-name miatt a szerverről helyileg a domainek a vm1 elhagyásával is működnek. Például:
Ez után indítsuk újra a gépet! És az /etc/resolv.conf-ba már csak a saját beállításaink kerülnek.
Összefoglalás
Ezzel már leváltottuk a hosts fájlos megoldást. Törölhetők belőle a hosztok. A névszerverrel sokkal rugalmasabb beállításokra van lehetőség. Nem kell mindent kézzel megadni és nem is kell két helyen. A kliensen és a szerveren is.
Egy virtuális gép hordozható lesz és bárhova visszük, a névszerver megadásával az összes domain elérhetővé válik. Ilyenkor a "forwarders" blokknál lehet különbség. Minden hálózatban más névszerverek lehetnek. Ha egyáltalán van további belső hálózat.
Már a dhcp kliens alapszintű beállítása sem jelenthet akadályt. Így egyre közelebb kerülünk egy igazán jól használható tesztkörnyezet kialakításához. Bár a Bind9 magától elindul, a webszerverből, MySQL-ből és PHP-ből is több verzió van, amit nem célszerű mind egyszerre elindítani minden alkalommal. Ennek megoldása is következik majd, de a 3 alkalmazás (Apache HTTPD, MySQL és PHP-FPM) kézi indításával, és a virtuális gép kikapcsolása helyetti altatás funkcióval már most is egész jók a lehetőségeink.
Végezetül mentsük el a virtuális gépet "wtk-vm1-v9-dns" néven!
A gép mentése csak javaslat. Akinek nincs elég helye a mentéshez, kihagyhatja ezt a lépést. Ha viszont vissza kell nyúlni egy verzióhoz, erre a névre fogok hivatkozni. Jelenleg az összes verzió mentésével együttesen 14,5 GB helyet foglal a merevlemezemen. Gépenként maximum 2GB-tal.
Források
