ugrás a tartalomhoz

Dinamikus Virtualhostok Apache 2.2 szerveren

alto1332 · 2013. Ápr. 9. (K), 16.19
Helló,

Adott egy localhost Apache 2.2 szerver Ubuntu 12.10-en és a /etc/hosts-ba hozzáadott valami.hu ami az 127.0.0.1-re mutat.

A cél a következő:
Ha megnyitom a weboldalt egy aldomainnel (akarmi.valami.hu) akkor a DocumentRoot a /home/akarmi/www mappa legyen, ellenkező esetben (valami.hu) a /var/www mappa.

Az első lépés sikerült a mod_vhost_alias modul engedélyezésével, majd a követhező scripttel, amit a /etc/apache2/apache2.conf fájl végén helyeztem el:

UseCanonicalName Off
VirtualDocumentRoot /home/%1/www/
(A teszt kedvéért a /etc/hosts-ba beraktam egy sub.valami.hu-t)

A másodikat viszont nem tudom hogyan kellene megvalósítani, ebben szeretném a segítségeteket kérni. Gondoltam az ErrorDocument 404-re, viszont az egyrészt nem is lenne elegáns, másrészt szeretnék majd 404-es hiba jelző oldalt.

A fenti script szétválaszthatóvá teszi az URL-t és %1-gyel az első részét (a legelső pontig) beilleszti szövegként és így a sub.valami.hu-t megnyitva a /home/sub/www mappát állítja be DocumentRootnak. A dolog lényege, hogy ne kelljen minden egyes aldomaint külön virtualhostként beállítani, hanem ezzel a pár sorral meg lehessen valósítani.

Azt is jó lenne megoldani, hogy ha www.sub.valami.hu-t nyitok meg, akkor ne a /home/www/www mappába irányítson át, hanem a /home/sub/www-be. Ugyanezt az aldomain nélküli változatnál, tehát www.valami.hu-ról ne a /home/www/www-t hanem a /var/www-t használja.

Előre is köszönöm a segítséget.
‹ apache belső hálózat 403 forbidden ›
 ■
1

Nem illik

vbence · 2013. Ápr. 9. (K), 16.28
Saját magadnak játékból lehet az ilyesmit egyetlen vhosttal kezelni, de ha igazi usereid vannak, illik nekik külön virtualhostokat létrehozni. Valószínűleg különböző beállításokra is lesz szükségük.
2

Tudom

alto1332 · 2013. Ápr. 9. (K), 16.39
Igazad van, ha valódi userek lennének pont a különböző igények miatt külön virtualhostot csinálnék mindenkinek, de jelenleg csak magamnak szeretnék egy ilyen teszt környezetet létrehozni. Ezt kellene minél kompaktabban megvalósítani.
3

Rewrite

vbence · 2013. Ápr. 9. (K), 17.17
Ha nem függsz a DocumentRoot környezeti változótól, megoldható Rewrite-tal.
<VirtualHost *:80>
    ServerName valami.hu
    ServerAlias *.valami.hu

    RewriteEngine On
    RewriteCond %{HTTP_HOST} (.*)\.valami\.hu [NC]
    RewriteRule (.*) /%1$1 [L]
</VirtualHost>
4

Tarhely

janoszen · 2013. Ápr. 9. (K), 18.00
Hosszu sztori kovetkezik. Anno jo par eve en is ugy kezdtem, hogy na akkor majd en tarhely szolgaltatot epitek es az milyen jo lesz. Kesobb a munkam lett egy ilyen tarhely szolgaltatast epiteni. Itt vannak a lepesek, amiken keresztul mentem.

1. lepes: manualis konfig

Kezzel hoztam letre a vhostokat, mindenhova irogattam bele a dolgokat. Azert, hogy ne legyen olyan bonyolult, en is kiserleteztem mindenfele VirtualDocumentRoot-tal meg ilyesmivel, de sajnos a kulonbozo Apache modulok (kulonosen a Rewrite) nem mukodott eleg jol vele.

2. lepes: FastCGI

Mar idejekoran eljutottam odaig, hogy a usereimet el kellene szeparalni jogosultsagok szintjen es SSH hozzaferest adni nekik. Meg mindig manualis konfiguracioval, de mar FastCGI-vel mentek a PHP-k. Sajnos karbantartasilag ez nem segitett sokat.

3. lepes: MPM ITK

Tovabbra is a user szeparacion dolgoztam es az MPM ITK-t nezegettem. Anno nem volt olyan fejlett a FastCGI tamogatas a PHP-ban, ezert folyamatosan voltak problemak. Sajnos mind biztonsagi, mint teljesitmeny szempontbol problemas volt a dolog.

4. lepes: sajat Apache modul

Amikor elkezdtem komolyabban dolgozni ezen a kerdesen, muszaj volt automatizalni. Ekkor kerult kepbe a kulonbozo dinamikus vhostokat lehetove tevo modulok. Mivel egyik sem volt igazan jo, elkezdtem egy sajatot fejleszteni. Ez sikerult is, napi tobb millio oldallekerdezest sikerult ezzel kiszolgalni.

5. lepes: mod_vhost_ldap

Ahogy uj rendszerekkel kiskerleteztem, egyre inkabb szerettem volna valami karbantarthato(bb) megoldast, amivel nem kell annyit foglalkozni. Igy kerult kepbe a mod_vhost_ldap. Ez egy LDAP szerverbol huzta a vhostokat, cachelt es egeszen jol mukodott. Eddigre a FastCGI mar egesz epkezlab allapotokat oltott, igy azzal hazasitottam ossze es buszken jelenthetem, szepen mukodott is.

6. lepes: virtualizacio

Ahova mar nem jutottam el mivel kikerultem a tarhely szolgaltatas temakorbol: a virtualizacio. A celom az volt, hogy minden felhasznalonak egy sajat virtualis gepet inditsak egy nagyon pici Apache-al benne, elotte pedig egy nginx teljesitene szolgalatot mint proxy.
5

Kombináld hagyományos VirtualHost-tal

Rimelek · 2013. Ápr. 9. (K), 19.49
Megnéztem én is ezt a mod_vhost_alias modult. Úgy nézem, pusztán a százalékjeles hivatkozásokkal ezt nem tudod megoldani. Nincs feltétel, hogy létezik-e a domain hivatkozott része. Ha pedig nem létező részre hivatkozol, akkor nem üres értéket kap, hanem egyáltalán nem működik.

Ha viszont a fődomaineket nem akarod ezzel kezelni, akkor a hagyományos virtuális hoszttal kombinálva megoldható:

UseCanonicalName Off
NameVirtualHost *:80

<VirtualHost *:80>
    ServerName valami.hu
    ServerAlias www.valami.hu
    DocumentRoot /var/www
</VirtualHost>

<VirtualHost *:80>
    ServerName sub.valami.hu
    ServerAlias *.valami.hu
    VirtualDocumentRoot /home/%-3/www
</VirtualHost>
Az első VirtualHost az alapértelmezett. A fődomain-re és a www-s változatára is az jön be a ServerAlias miatt. Ha nincs aldomain, akkor az alap vhost lesz érvényes.

Kell egy fix aldomain, ami lehet a ServerName helyén, hogy megkülönböztesd a default-tól. Illetve ServerAlias minden aldomainje a valami.hu -nak.

Ahhoz, hogy a www a VirtualDocumentRoot -ba se kavarjon be, nem az első ( %1 ) részt kell venni a domainből, hanem jobbról a harmadikat ( %-3 ). Ami az előtt van, már lehet www vagy bármi más is. De ha a hosts fájlban csak a www-t engedélyezed, akkor úgyis csak azzal fog működni.
6

PHP-FPM

alto1332 · 2013. Ápr. 13. (Szo), 18.47
Köszönöm a válaszokat, mindegyik nagyon sokat segített! Jelenleg PHP-FPM-mel bűvészkedek. Sikerült felrakni az Apache mellé, egyedül a jogokkal van gond, de azokkal nagyon. Több helyen olvastam, hogy www-data-ként futtatja a fájlokat, de nekem úgy kellene hogy a tulajdonos jogaival tegye ezt.
Próbaként létrehoztam egy tomi.php-t a /var/www-ben aminek a tartalma a következő:

<?php echo system("cat /etc/passwd"); ?>
Ezt állítottam be rá:

chown -R tomi:tomi /var/www/tomi.php
Sajnos még mindig lefuttatja a system()-et. Hogyan lehetne megoldani, hogy ezt és a hasonló függvényeket ne tudja használni?
Ezen kívül ott tartok, hogy írtam egy bash scriptet, ami létrehoz egy új virtualhostot - documentrootot, subdomaint a paraméternek megadott adatok alapján állít be.
7

php.ini

Pepita · 2013. Ápr. 13. (Szo), 19.36
Hogyan lehetne megoldani, hogy ezt és a hasonló függvényeket ne tudja használni?
disable_functions (php.ini)
Lehet, hogy van sokkal jobb megoldás is, azt majd valaki okosabb...
8

php safe_mode

alto1332 · 2013. Ápr. 13. (Szo), 20.09
Gondoltam már rá, de előfordulhat, hogy kihagyok valamit. Kb. ezt csinálta anno a safe_mode is, de azt már kivették a PHP-ból.
9

CGI

vbence · 2013. Ápr. 13. (Szo), 20.39
Ez van, ha a PHP-t modulként futtatod. Proclub írta a fstcgi-t. Itt a Weblaboron is van egy részletes írás a témáról. Keress suexec-re.
10

PHP-FPM-et (FastCGI Process

alto1332 · 2013. Ápr. 13. (Szo), 21.00
PHP-FPM-et (FastCGI Process Manager) használok helyette, mivel több beállításra van lehetőség.

Egyébként ez azt jelenti, hogy a PHP-FPM önmagában nem alkalmas a fájlok tulajdonosaik jogaival való futtatására? Tehát kell FPM mellé suexec?
11

Amit te akarsz, azt úgy

H.Z. · 2013. Ápr. 13. (Szo), 21.08
Amit te akarsz, azt úgy láttam, a suexec sem tudja.
Nem ismerem, csak ezt a topikot látva futottam át a leírását, de nekem úgy tűnt, az is csak virtualhost-hoz/userdir-hez tud önálló usert rendelni, de olyat, mint op.rendszer szinten a suid bit beállításával... nekem úgy tűnt, olyat az sem tud.
A PHP-FPM-et meg a jelenleg rendelkezésemre álló linuxon nem tudtam beüzemelni.
12

oprendszer szintű jogok

Rimelek · 2013. Ápr. 14. (V), 12.15
Azért olvashatja a felhasználó az /etc/passwd -t, mert azt minden linux felhasználó olvashatja. Olvasási joga mindenkinek van rá. Az /etc/shadow-ra már nincs. Azt nem tudnád olvasni akármilyen userrel.

Használhatsz open_basedir -t is, amivel pl fopen-nel vagy file_get_contents függvénnyel nem tudnád megnyitni a passwd fájlt, de system-mel továbbra is. Marad a függvénytiltás. Illetve janoszen említette a virtualizációt. Vagy van a "chroot", amivel bezárhatod a usert egy könyvtárba. És oda olyan fájlokat teszel, amiket egy részt muszáj, más részt amit még nem sajnálsz. Ezzel a témával foglalkozom egy ideje, de idáig még nem jutottam el. Janoszen tudna több infóval szolgálni. Mivel ő írta azt a bejegyzést is, amiből én is tanultam az fpm-ről. Bár csak egyszer próbáltam ki chroot-tal.

A usert viszont, aminek a nevében a php futni fog, nem a fájl jogosultságával kell állítani. Hanem a php-fpm.conf -ban. A fájl joga csak annyit ér, hogy ha a userednek nincs megfelelő joga a fájlra, akkor nem fogod tudni futtatni.

Na szóval összegezve a lényeg: Nem kell suexec, sem suphp az adott user nevében futtatáshoz, de a jogosultságokat oprendszer szinten kell kezelned. Illetve a php beállításait állíthatod "pool-onként".

Ennyit tudtam hozzászólni. De az ismerkedés még folyamatban van ezekkel a megoldásokkal.