Virtuális hoszt Apache HTTPD 2.2-ben és 2.4-ben

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:

  1. mkdir -p /var/www/vhosts/vm1/{a22,a24}/{_logs,www,{p5414,p5324,p5217}/{_logs,www}}

Ezen kívül kellene mindkét Apache szerverhez egy mappa a vhost-oknak.

  1. mkdir -p /opt/apache/{2.2,2.4}/conf/extra/vhost

Engedélyezzük a virtuális hosztok fájlját mindkét Apache-ban!

  1. nano /opt/apache/2.2/conf/httpd.conf

Vegyük ki a következő sor elől a kettőskeresztet:

  1. #Include conf/extra/httpd-vhosts.conf

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.

  1. <VirtualHost *:80>
  2.     ServerAdmin webmaster@dummy-host.example.com
  3.     DocumentRoot "/opt/apache/2.4/docs/dummy-host.example.com"
  4.     ServerName dummy-host.example.com
  5.     ServerAlias www.dummy-host.example.com
  6.     ErrorLog "logs/dummy-host.example.com-error_log"
  7.     CustomLog "logs/dummy-host.example.com-access_log" common
  8. </VirtualHost>
  9.  
  10. <VirtualHost *:80>
  11.     ServerAdmin webmaster@dummy-host2.example.com
  12.     DocumentRoot "/opt/apache/2.4/docs/dummy-host2.example.com"
  13.     ServerName dummy-host2.example.com
  14.     ErrorLog "logs/dummy-host2.example.com-error_log"
  15.     CustomLog "logs/dummy-host2.example.com-access_log" common
  16. </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.

  1. echo "Include conf/extra/vhosts/*.conf" > /opt/apache/2.4/conf/extra/httpd-vhosts.conf

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:

  1. NameVirtualHost *:80

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:

  1. echo "Include conf/extra/vhosts/*.conf" > /opt/apache/2.2/conf/extra/httpd-vhosts.conf
  2. 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!

  1. cd /opt/apache/2.4/conf/extra/vhosts/

Hozzuk létre az a24.vm1 domainhez tartozó virtuális hosztot:

  1. nano 001-a24.vm1.conf

A tartalma pedig a következő:

  1. <VirtualHost *:80>
  2.     ServerName a24.vm1
  3.     ServerAlias www.a24.vm1
  4.      
  5.     DocumentRoot "/var/www/vhosts/vm1/a24/www"
  6.  
  7.     ErrorLog "/var/www/vhosts/vm1/a24/_logs/error.log"
  8.     CustomLog "/var/www/vhosts/vm1/a24/_logs/access.log" common
  9.  
  10.     <Directory "/var/www/vhosts/vm1/a24/www">
  11.         Require all granted
  12.     </Directory>
  13. </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:

  1. Order allow,deny
  2. 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.

  1. echo "a24.vm1" > /var/www/vhosts/vm1/a24/www/index.html

Indítsuk el a szervert és nyissuk meg böngészőben az a24.vm1 oldalt!

  1. /opt/apache/2.4/bin/apachectl restart

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.

  1. cp 001-a24.vm1.conf 002-p5414.a24.vm1.conf
  2. 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:

  1. <VirtualHost *:80>
  2.     ServerName p5414.a24.vm1
  3.     ServerAlias www.p5414.a24.vm1
  4.      
  5.     DocumentRoot "/var/www/vhosts/vm1/a24/p5414/www"
  6.  
  7.     ErrorLog "/var/www/vhosts/vm1/a24/p5414/_logs/error.log"
  8.     CustomLog "/var/www/vhosts/vm1/a24/p5414/_logs/access.log" common
  9.  
  10.     <Directory "/var/www/vhosts/vm1/a24/p5414/www">
  11.         Require all granted
  12.     </Directory>
  13. </VirtualHost>

Ez után a beállítások érvénybelépéséhez újra kell indítani a szervert

  1. /opt/apache/2.4/bin/apachectl restart

Készítsünk neki is egy index.html-t, majd állítsuk be a hosts" fájlba az új domaint is!

  1. echo "p5414.a24.vm1" > /var/www/vhosts/a24/p5414/www/index.html

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!

  1. cp 001-a24.vm1.conf 003-p5324.a24.vm1.conf
  2. sed s/a24\\.vm1/p5324.a24.vm1/g -i 003-p5324.a24.vm1.conf
  3. 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.

  1. /opt/apache/2.4/bin/apachectl restart
  2. 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:

  1. cp 001-a24.vm1.conf 004-p5217.a24.vm1.conf
  2. sed s/a24\\.vm1/p5217.a24.vm1/g -i 004-p5217.a24.vm1.conf
  3. 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.

  1. /opt/apache/2.4/bin/apachectl restart
  2. 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:

  1. cp * /opt/apache/2.2/conf/extra/vhosts/
  2. cd /opt/apache/2.2/conf/extra/vhosts/
  3. rename s/a24\\.vm1/a22.vm1/ *
  4. sed 's/Require all granted/Order allow,deny\n        Allow from all'/ -i *
  5. /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.

  1. echo "a22.vm1" > /var/www/vhosts/vm1/a22/www/index.html

p5414.a22.vm1

  1. echo "p5414.a22.vm1" > /var/www/vhosts/vm1/a22/p5414/www/index.html

p5324.a22.vm1

  1. echo "p5324.a22.vm1" > /var/www/vhosts/vm1/a22/p5324www/index.html

p5217.a22.vm1

  1. echo "p5217.a22.vm1" > /var/www/vhosts/vm1/a22/p5217/www/index.html

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.

  1. RewriteEngine on
  2. 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:

  1. # vhosts
  2. 192.168.56.2    a24.vm1
  3. 192.168.56.2    www.a24.vm1
  4. 192.168.56.2    p5414.a24.vm1
  5. 192.168.56.2    www.p5414.a24.vm1
  6. 192.168.56.2    p5324.a24.vm1
  7. 192.168.56.2    www.p5324.a24.vm1
  8. 192.168.56.2    p5217.a24.vm1
  9. 192.168.56.2    www.p5217.a24.vm1
  10.  
  11. 192.168.56.3    a22.vm1
  12. 192.168.56.3    www.a22.vm1
  13. 192.168.56.3    p5414.a22.vm1
  14. 192.168.56.3    www.p5414.a22.vm1
  15. 192.168.56.3    p5324.a22.vm1
  16. 192.168.56.3    www.p5324.a22.vm1
  17. 192.168.56.3    p5217.a22.vm1
  18. 192.168.56.3    www.p5217.a22.vm1
  19.  
  20. # mysql
  21. 192.168.56.2    m56.vm1
  22. 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

Kategóriák: 
Megosztás/Mentés

Új hozzászólás