A virtuális hoszt egy megoldás, amivel egy Apache webszerver IP-től vagy domaintől függően tud egyedi szerverbeállításokat biztosítani egy webes alkalmazásnak.
Így kitalálhatunk bármilyen domain nevet, amit az adott operációs rendszer "hosts" fájljában a szerver valamelyik IP címére irányíthatunk. Innentől pedig már nem csak az IP címet, de hosszú könyvtárstruktúrát sem kell megjegyezni egy másik weboldal eléréséhez, mivel saját, rövid nevet kaphat. Feltéve persze, hogy az megjegyezhető.
Nagyobb előny viszont, hogy saját gyökérkönyvtárat kaphat a virtuális hoszt, és egyedi naplófájlokat. A különböző domainekhez tartozó könyvtárak tetszőlegesen szervezhetők. Ezzel pedig a könyvtárakra vonatkozó beállításokkal közös paraméterek alakíthatók ki bizonyos domainekhez.
Ezen kívül virtuális hoszthoz is rendelhető tetszőleges PHP verzió.
Ezt a fejezetet tehát a virtuális hosztok készítésének szentelem.
Konfigurációs fájl
Gyakorlatilag bármelyik fájl tartalmazhatja a virtuális hosztokat. Akár közvetlenül a "httpd.conf" is. Vagy egyes esetekben az "apache.conf" fájl. De célszerű mégis külön tartani a többi beállítástól.
Egy "apt-get" -tel telepített Apache szerver virtuális hosztjainak beállításai a "/etc/apache2/sites-available" könyvtárba kerülnek. Minden virtuális hoszt külön fájlba. És csak a bekapcsolt virtuális hosztok vannak linkelve a "sites-enabled" könyvtárban, ahonnan "Include"-dal tudja betölteni a fő konfigurációs fájl a teljes mappa összes fájlját. Az engedélyezése így gyakorlatilag ennek az "Include"-nak a kivétele a megjegyzésből a "httpd.conf" -ban.
Ha saját magunk fordítjuk az Apache szervert, akkor alapértelmezetten a telepítési könyvtáron belül, a "conf/extra/httpd-vhosts.conf" fájlba kerülnek a virtuális hosztok definíciói. Ez a fájl van betöltve "Include"-dal a "httpd.conf" -ban. Pontosabban lesz akkor, ha kivesszük a sor elejéről a kettőskeresztet.
Nekem tetszik a külön fájlos megoldás. Egy virtuális hoszt leírása egyébként sem biztos, hogy rövid. Így könnyebb benne eligazodni. A szimbolikus linkeket viszont már nem erőltetem. Bár megvan az előnyük azoknak is.
Könyvtárstruktúra
Mint említettem, a virtuális hosztok saját gyökérkönyvtárat kaphatnak. Mielőtt gondolkodás nélkül nekiáll valaki virtuális hosztokat készíteni, nem árt átgondolni, hogy hogyan célszerű a könyvtárakat létrehozni. Nem hiszem, hogy volna univerzális, tökéletes megoldás. De ismerve a célokat, lehet praktikus felépítést kialakítani.
Szempontok
A választott felépítést több tényező befolyásolhatja. A témában, a még mondhatni, amatőr fejemmel a következőket képzelem el.
Biztonság
Mi a célcsoport? Kell-e a könyvtárakat egy virtuális, zárt környezetbe kényszeríteni ( chroot ). Az úgynevezett "chroot-olt" környezetben eleve vannak kötelező könyvtárak és programok. Azokat is bele kell kalkulálni.
Van-e egyéb biztonsági kérdés, ami indokol egy struktúrát?
Kezelhetőség
Mennyire átlátható, kezelhető a könyvtárstruktúra? Milyen domaineket fogunk beállítani?
Ha mindenféle TLD-nek helyet kell adni, nem spórolható ki annak jelölése sem.
Ha nagyon sok domain lesz, célszerű valamilyen követhető, világos logika szerint alkönyvtárakba szervezni a hosztokat.
Konfiguráció
Milyen jellegű közös vagy egyedi beállításokra lesz szükség? Ha például az aldomaineknek kizárólag a fődomain gyökérkönyvtárán belül biztosítunk helyet, akkor a fődomain gyökérkönyvtárába rakott htaccess hatással lehet az aldomainekre. Az almappákban felülírni pedig nem biztos, hogy kényelmes megoldás. Főleg előre nem látott opciók alapján.
Ha a fődomain gyökerén kívül vannak az aldomainek, lehetséges-e más beállítás miatt könyvtárnév ütközés, ami kizárja egyes aldomainek használatát?
Elérhető eszközök
Milyen modulok elérhetők a szerverhez, amik segíthetnek a kényelmesebb konfigurációban? Ha az elérhető modulok egy szűkebb strukturálási lehetőséget biztosítanak, de a modul előnyei fontosak, akkor fel kell áldozni egy másik előnyt.
Haszon és befektetett munka aránya
Van az a mondás, hogy bármit lehet, csak akarni kell és több munkával jár. A kérdés az, hogy megéri-e ez a munka. A megoldás előnyei olyan mértékűek-e, hogy kifizetődő a befektetett energia, a ráfordított idő és költség. Ha nem, bármilyen szép is volna az a megoldás, nem érdemes vele vesződni.
Az elkészítendő
Az első könyvtár az aktuális TLD lesz, amibe a hozzá tartozó fődomainek kerülnek. Így a saját, hamis TLD-knek is lesz hely a tesztszerveren, de szükség esetén, .hu, .com, stb... TLD-k is használhatók.
Minden virtuális hoszt könyvtára a következő mappákat tartalmazza
- _logs
- www
- aldomain1
- aldomain2
- . . .
A tripla pont természetesen nem mappa, hanem további aldomainekre utalás. A "_logs" mappába kerülnek a naplófájlok. Aláhúzás karakterrel kezdődik, mert azt nem tartalmazhat domain név. Így nincs ütközés. A "www" mappa a fődomain gyökere. Mivel általában a domaineket www-vel is el lehet érni, és gyakorlatilag az is egy aldomain, pont jó helyen van itt. Minden további aldomain bekerülhet ebbe a könyvtárba. Az aldomainek könyvtára pedig pontosan ugyanígy épül fel.
Ezzel elérjük azt, hogy egy domain naplófájljai mindig kéznél legyenek, és ne kelljen máshol keresgélni. Persze, ha az összes naplófájl érdekelne valakit, akkor ez hátrány is lehetne. De még mindig lehet szimbolikus linkekkel segíteni ezen.
Jól látható, hogy milyen aldomainjei vannak az adott domainnek. Lehet a fő- és aldomainekre egyaránt kiterjedő beállításokat készíteni akár a virtuális hoszt definíciójában, akár htaccess-szel helyben. De lehet kizárólag a fődomaint érintő htaccess-t elhelyezni a "www" könyvtárban.
Egy domain és annak összes aldomainje kiadható egy konkrét felhasználónak. Az érzékeny fájlokra lehet csak olvasási jogot adni, így ha FTP hozzáférést kap a felhasználó a domainjéhez, a naplófájlokat nem változtathatja, de megnézheti.
"chroot-olt" környezet beállítására ez a felépítés nem alkalmas. Az viszont túlmutat ennek a fejezetnek a témáján.
Lehetnek érvek a fent felvázolt konstrukció ellen, de tesztszerverhez azt hiszem, pont megfelelő.
Virtuális hosztok elkészítése
A virtuális hosztokat az előző fejezetekben elkészített szerverekre alapozva építem fel. Az elv viszont bármely környezetben ugyanaz.
Terep előkészítése
Lépjünk be root-ként a szokásos sudo su ( vagy su - root ) paranccsal!
Az a22 és a24 domaineken belül is létre kell hozni a fentebb írt struktúrát a következő 3 aldomainnel: p5414, p5324, p5217.
A felsorolt három aldomain a PHP verzióira utal.
Ezeket lehetne lépésről lépésre is, de a "bash" shell-ben lehetőség van egyetlen paranccsal megoldani:
Ezen kívül kellene mindkét Apache szerverhez egy mappa a vhost-oknak.
Engedélyezzük a virtuális hosztok fájlját mindkét Apache-ban!
Vegyük ki a következő sor elől a kettőskeresztet:
A "CTRL+W" billentyűkombinációval lehet keresni a "httpd-vhosts" kifejezésre.
Mentsük el "CTRL+O"-val, lépjünk ki "CTRL+X"-szel, majd ismételjük meg ugyanezt a 2.4 -es szerver azonos nevű fájlban!
A fent említett két fájlban két előre beállított virtuális hoszt van.
ServerAdmin webmaster@dummy-host.example.com
DocumentRoot "/opt/apache/2.4/docs/dummy-host.example.com"
ServerName dummy-host.example.com
ServerAlias www.dummy-host.example.com
ErrorLog "logs/dummy-host.example.com-error_log"
CustomLog "logs/dummy-host.example.com-access_log" common
</VirtualHost>
<VirtualHost *:80>
ServerAdmin webmaster@dummy-host2.example.com
DocumentRoot "/opt/apache/2.4/docs/dummy-host2.example.com"
ServerName dummy-host2.example.com
ErrorLog "logs/dummy-host2.example.com-error_log"
CustomLog "logs/dummy-host2.example.com-access_log" common
</VirtualHost>
Ezekre most nem lesz szükség. Sajátot írunk, de hasonló módon. Cseréljük az Apache 2.4 konfigurációs fájljának tartalmát az egyetlen Include sorra, ami a vhosts könyvtár fájljait olvassa majd. Azok közül is csak azokat, amik conf -ra végződnek.
Az Include utáni útvonalat a szerver telepítési könyvtárától kell kezdeni.
Ugyanezt kellene megismételni a 2.2-es szervernél, de ott szükség van még a következő sorra is:
Ez felel ugyanis azért, hogy a ServerName -mel is megkülönböztethetők legyenek a virtuális hosztok, ne csak IP és port alapján. Apache 2.4-ben ez már automatikusan így működik. Hogy ezt a sort a fájlban hova írjuk, annak nincs jelentősége. Lehet a fájl elején, a végén vagy valahol közben is. Én az elejére szeretem tenni, de hogy a fenti parancsot minél kevésbé keverjem meg, most a végére írjuk:
echo "NameVirtualHost *:80" >> /opt/apache/2.2/conf/extra/httpd-vhosts.conf
FONTOS észrevenni, hogy 2.4 helyett most 2.2-t írtam és a második sorban ">>" jel van ( hozzáfűzés ), nem pedig csak ">" ( felülírás ).
Természetesen a hagyományos módon is lehet a fájlt szerkeszteni. De ha már pici közünk van a Linux-hoz, érdemes pár apró trükköt megtanulni.
A NameVirtualHost után a csillag helyett IP-t is lehetett volna írni. De most egyetlen IP-n figyel egy szerver, így lehet azt az összes 1-et engedélyezni. És eggyel kevesebb dolgot kell átírni IP váltás esetén.
a24.vm1
Lépjünk be a vhosts config könyvtárba!
Hozzuk létre az a24.vm1 domainhez tartozó virtuális hosztot:
A tartalma pedig a következő:
ServerName a24.vm1
ServerAlias www.a24.vm1
DocumentRoot "/var/www/vhosts/vm1/a24/www"
ErrorLog "/var/www/vhosts/vm1/a24/_logs/error.log"
CustomLog "/var/www/vhosts/vm1/a24/_logs/access.log" common
<Directory "/var/www/vhosts/vm1/a24/www">
Require all granted
</Directory>
</VirtualHost>
A ServerName lesz a virtuális hoszt fő domainje. De elérhető lesz a ServerAlias után írt címen is. A DocumentRoot a gyökérkönyvtár. Az ErrorLog pedig majd a hibaüzeneteket tartalmazza. A CustomLog az egyéb eseményeket tartalmazza. Jelen esetben a szervereléréseket. Az utána írt "common" pedig egy formátumot jelöl. De erre it most nem térek ki.
Ami inkább szóra érdemes, az a "Directory" blokk. Itt a könyvtárra vonatkozóan adhatunk meg beállításokat. Ami mindenképp kell, az az engedély a fájlok eléréshez. Apache 2.2-ben a "Require all granted" helyett ezt kellett volna írni:
Allow from all
A www könyvtár viszont még üres. Tegyünk bele egy index.html-t a domain nevével! Ezzel könnyen azonosítható, hogy a helyes hosztot sikerült-e elérni.
Indítsuk el a szervert és nyissuk meg böngészőben az a24.vm1 oldalt!
Ehhez be kell állítani a hosts fájlban ( a gazda és a vendég operációs rendszerben is célszerű ) az IP-domain párokat, ahogy azt az Apache telepítésénél leírtam: Link
p5414.a24.vm1
Nagyon hasonló a beállítása, mint az a24.vm1 domainnek. Legyünk kicsit lusták és csak másoljuk az előző config fájlt és írjuk át a domaint és az útvonalakat.
nano 002-p5414.a24.vm1.conf
A szervernévben és aliasban kell az "a24"-et "p5414.a24"-re bővíteni, illetve az útvonalakban az "a24"-et "a24/p5414" -re átírni. A fájl tartalma így:
ServerName p5414.a24.vm1
ServerAlias www.p5414.a24.vm1
DocumentRoot "/var/www/vhosts/vm1/a24/p5414/www"
ErrorLog "/var/www/vhosts/vm1/a24/p5414/_logs/error.log"
CustomLog "/var/www/vhosts/vm1/a24/p5414/_logs/access.log" common
<Directory "/var/www/vhosts/vm1/a24/p5414/www">
Require all granted
</Directory>
</VirtualHost>
Ez után a beállítások érvénybelépéséhez újra kell indítani a szervert
Készítsünk neki is egy index.html-t, majd állítsuk be a hosts" fájlba az új domaint is!
p5324.a24.vm1
Ennél a domainnél legyünk nyugodtan még lustábbak. Másoljuk a conf fájlt és a "sed" programmal cseréljük ki a szükséges részeket!
sed s/a24\\.vm1/p5324.a24.vm1/g -i 003-p5324.a24.vm1.conf
sed s/vm1\\/a24/vm1/a24\\/p5324/g -i 003-p5324.a24.vm1.conf
Ekkora tartalomnál nem feltétlenül gyorsabb, de legalább nem marad ki semmi. Most pedig jöhet a szerver újraindítása a teszteléshez és az index.html létrehozása, valamint a hosts fájlba az új domain felvétele.
echo "p5324.a24.vm1" > /var/www/vhosts/vm1/a24/p5324/www/index.html
p5217.a24.vm1
Gyakorlatilag meg kell ismételni az előző lépéseket az új domainnel:
sed s/a24\\.vm1/p5217.a24.vm1/g -i 004-p5217.a24.vm1.conf
sed s/vm1\\/a24/vm1/a24\\/p5217/g -i 004-p5217.a24.vm1.conf
Majd: Szerver újraindítása, index.html létrehozása és a hosts fájlba az új domain felvétele.
echo "p5217.a24.vm1" > /var/www/vhosts/vm1/a24/p5217/www/index.html
a22.vm1
A 2.2-es Apache szerverhez szinte ugyanezek a beállítások kellenek. A különbség a "Require all granted" sor cseréje a korábban említett, régebbi alternatívájára és természetesen az "a24" is változik "a22"-re. Így ugyanúgy másolhatjuk a fájlokat, csak most a fájl neve is változik a domainnek megfelelően:
cd /opt/apache/2.2/conf/extra/vhosts/
rename s/a24\\.vm1/a22.vm1/ *
sed 's/Require all granted/Order allow,deny\n Allow from all'/ -i *
/opt/apache/2.2/bin/apachectl start
Ezzel már a nagyobb munkát elvégeztük. De még van néhány lépés. A hosts fájlok szerkesztése és az index.html-ek elhelyezése.
p5414.a22.vm1
p5324.a22.vm1
p5217.a22.vm1
Virtuális hoszt alias
Van egy "mod_vhost_alias" nevű Apache modul, amivel pár sorban akárhány virtuális hosztot leírhatunk. Viszont nem bármilyen módon. Ha van egy domain, aminek az aldomainjeit kell csak egyszerűsítve definiálni, Apache újraindítása nélkül, akkor jól használható. Egyszerre többszintű aldomaineket előre meghatározni viszont nem lehet vele. Persze még így is felgyorsíthatja és megkönnyítheti a beállításokat.
Hátránya még, hogy csak a gyökérkönyvtárat és esetleg ScriptAlias-t lehet vele kezelni, de a naplózás alapesetben egy fájlba történik. Ezt meg lehet trükközni, ha a naplózást "pipe" segítségével oldjuk meg. De ez megint csak nem fér bele ebbe a fejezetbe.
Összefoglalás
Ennyi lett volna a virtuális hosztok beállítása. Ennek mintájára lehet a többit is. Ezek viszont majd a különböző PHP verziók hosztjai lesznek további konfigurációval.
A fájlokat azért nem tettem letölthetővé, mert egyszer mindenkinek be kell gépelnie legalább egy fájl forrását. A többit pedig jórészt másoltuk.
Látható, hogy a másolás is elég sablonos. Így akár ennek mintájára haladó felhasználók szkriptet is készíthetnek a munka tovább könnyítésére.
Mivel a virtuális hosztok fájljait ".conf" kiterjesztéssel láttuk el, és a "httpd-vhosts.conf" -ban csak ezeket olvassa be a szerver, kikapcsolható bármeliyk hoszt a kiterjesztés "conf-off" -ra változtatásával és a szerver újraindításával.
Lényeges a sorrend, mert a szerver a legelsőt tekinti alapértelmezettnek. Ha nem talál a kérésnek megfelelő hosztot, az első lesz az aktív. Ezen kívül előfordulhat olyan, hogy egy kérés több szabálynak is megfelel. Olyankor az első illeszkedő szabály szerinti hosztot választja az Apache. Ezért vannak számozva a fájlok. Így egyértelmű a betöltődés sorrendje.
Ha arra is szükség van, hogy egy nem definiált domainre ne töltődjön be semmi, csak egy hibaüzenet, akkor az első hoszton minden kérést egy hibaüzenetre kell irányítani a "rewrite" modullal.
RewriteRule .* /undefined-vhost.html
A hosts fájl a gazda gépen és a Debian virtuális gépen is a következő szabályokat tartalmazza nálam:
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
Végül pedig mentsük el a virtuális gépet egy exporttal "wtk-vm1-v6" néven, hogy ezek a beállítások megmaradjanak akár többféle alternatív további konfiguráció kialakításához!
Források
