PHP FPM beállítása Apache HTTPD 2.2 és 2.4 alatt

Írtam már a mod_cgi/mod_cgid és a mod_fcgid modulokról, amikkel a PHP több verzióját futtathatjuk egyszerre. A PHP FPM viszont egy ezeknél is jobb megoldás. Azért mégsem tejesen új, mivel a mod_fastcgi vagy mod_fcgid Apache modulok egyike kell hozzá. Bár előbbiről nem esett még külön szó az említés szintjén felül, most ezt is telepítjük, mivel az Apache HTTPD 2.2 nem támogatja a szükséges mod_proxy_fcgi modult a mod_fcgid használatához.

A fejezet végén tehát már ismerni fogjuk mindkét lehetőséget és mindkét webszerver képes lesz bármely PHP verziót FPM-en keresztül futtatni tetszőleges felhasználó nevében.

Előbb azonban mindenképp javaslom a PHP telepítéséről szóló fejezet elolvasását, ahol az FPM telepítéséhez szükséges konfigurálásról írtam. Valamint az előző CGI megoldásokról szólót is.

Előkészületek, előismeret

Már az eddigiek után talán mondanom sem kell, de root jogra szükség lesz a sudo su vagy su - root parancsok egyikével. Amelyik működik.

Miért?

Mielőtt bármit állítgatnánk, értsük meg, hogy miért is tesszük és hogy ellenőrizzük a sikerességét! Azt a tényt, hogy ezzel több PHP verziót is lehet egyidejűleg használni, már kellően sokat emlegettem. És ez már FPM nélkül is működött. Ahhoz viszont, hogy a PHP egy tetszőleges felhasználó nevében futhasson, további intézkedések kellenek. Ez szintén megoldható lenne FPM nélkül, az FPM viszont ennél többről szól.

Egy helyen menedzselhetők a processek kezelésének tulajdonságai, a felhasználó és különböző környezeti változók. De akár egy chroot-olt környezet is használható vele. Illetve jó sebességet is el lehet érni. Profikat megszégyenítő beállításokat nem fogunk itt végezni, de nem is ez a cél.

Az, hogy a PHP-t egy adott felhasználó nevében lehet futtatni, azért lényeges, mert olykor a PHP-nek is tudnia kell fájlokat kezelni. Ehhez viszont kell, hogy legyen rá joga. Amihez pedig legalább a könyvtárak csoportját kell megfelelőre állítani, vagy mindenkinek kell rá jogot adni. Vagy egyszerűen a php-t kell tulajdonosnak kijelölni. Ekkor viszont a saját felhasználóval nem lehet könnyen szerkeszteni.

Ráadásul két teljesen független PHP alkalmazás, akár ( de nem feltétlenül) különböző valós személyek kezében ( chroot nélkül ) képes belelesni vagy akár belemódosítani a másik fennhatósága alatt álló fájlokba. Ha ezt körülményesen is fogalmaztam, annyi érezhető, hogy bonyodalmakat okoz az egyfelhasználós megoldás.

Tesztelés

Hogy ne csak "beszéljünk" erről, mutatok egy példát. Indítsuk el a 2.4-es szervert:

Elsőként ellenőrizzük le, hogy jelenleg mi is a felhasználója a PHP-nek! Ezt a következő módon: Készítünk egy whoami.php -t a p5414-es aldomain dokumentum gyökérebe.

Tartalomként pedig írunk egy sort, ami a shell-t használva kiírja az aktuális felhasználót:

Az eredménye nálam "daemon". Ez az Apache felhasználója. Ha lefuttatjuk parancssorban a

parancsot, hasonló kimenetet ad:

Látható, hogy minden fájl és könyvtár tulajdonosa a "root" felhasználó. Ezzel hoztam létre a könyvtárakat és a fájlokat. Készítsünk egy touch.php fájlt, ami csak megpróbál létrehozni egy teszt.txt fájlt:

A tartalma

Az eredménye pedig:

A PHP-nek nincs hozzá joga. Jó, akkor adjuk át a tulajdoni jogot a mappára a daemon felhasználónak!

Az "ls" parancsot használva most ez látszik az aktuális könyvtárnál:

A touch.php pedig hiba nélkül lefut és létrehozza a teszt.txt fájlt.

Viszont innentől minden virtuális hosztnak van hozzá joga. A fájlt csak daemon vagy root userként lehet módosítani, de daemon-ként is csak root-ból lehet belépni. Ha pedig az olvasási jogot is elvenném az idegen felhasználóktól, akkor olvasni is csak így tudnám. Ez akár lehet cél is. Amikor helyi gépen, SSH-n keresztül vagy FTP-n dolgozunk, könnyen kopaszodáshoz vezethet manuális beavatkozással.

Apache 2.4

Most, hogy már remélhetőleg világosabb, miért és hová tartunk, jöhet az első szerver felkészítése mindhárom PHP verzióra. Az 5.3 és 5.4 -es PHP-val még könnyű dolgunk lesz. Az 5.2-nél trükközni kell.

Két modulra mindenképpen szükség lesz, amiket engedélyezni kell a httpd.conf-ban. Ezek a mod_proxy és a mod_proxy_fcgi. Ez teszi lehetővé, hogy megszólítsuk az FPM-et.

A

és a

sorok elejéről kell kivenni a kettőskeresztet

PHP 5.4.14

Ha megnézzük a phpinfo kimenetét, még "CGI/FastCGI" látható a "ServerAPI" mellett. Ez az FPM beállítása után meg fog változni "FPM/FastCGI" -ra. Lássuk!

Virtuális hoszt konfiguráció

Az előző megoldásoknál is mindig volt pár sor a virtuális hoszt definíciójában, ami valahogyan hivatkozott a használandó PHP-re. Itt most TCP-n keresztül IP és port segítségével történik a kommunikáció. A PHP-hez tartozik egy "php-fpm" program, ami a háttérben figyel adott IP-port párokon. Ezeket hívjuk pool-oknak. Amikhez egyedi beállításokat szabhatunk.

Ahhoz, hogy socket-en keresztül működjön a kommunikáció, meg kéne hackelni az Apache-ot. Erre egy patch-re lenne szükség, amit jómagam nem próbáltam ki, de a következő oldalon írnak róla:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54101

Haladók saját felelősségre ügyeskedhetnek.

Nyissuk meg a p5414 aldomainhez tartozó virtuális hoszt definíció fájlját:

A <Directory> blokk elé kerüljön a következő sor:

A korábbi, cgi wrapper-t használó megoldáshoz tartozó sorokat törölni lehet. Vagy csak megjegyzésbe tenni. A fenti sor a "ProxyPassMatch" után írt reguláris kifejezésre illeszkedő fájlokat fogja elküldeni az FPM-nek feldolgozásra a jobb oldalon megadott IP-n és porton.

Az IP-port párosoknak minden pool-ban egyedinek kell lennie és nyilván más alkalmazás sem foglalhatja őket együtt. A virtuális hosztok fájljaihoz hasonlóan adtam meg az IP-t. Azaz a fix 127-es után 0.0.2 következik, ahogy a vhost fájl neve is 002-vel kezdődik. A port pedig az alapértelmezett 9000. Ezt persze ugyanígy lehetne a port változtatásával is megoldani.

A port után a futtatandó fájl útvonalát kell írni a szerver gyökeréhez viszonyítva. Ennek a végén egy $1 található, ami a reguláris kifejezésben levő zárójeles rész behelyettesítését jelenti. Abban pedig a / jelet szándékosan tettem a zárójelen kívülre, mivel az útvonal tartalmazni fogja. A $1 előtti útvonal a virtuális hoszt gyökere, így ahhoz képest keres minden fájlt.

Gyanakodva, hogy mi van, ha "../"-rel könyvtárt váltok az url-ben, kipróbáltam, ki lehet-e szökni a gyökérből. De nem lehet.

A világosság kedvéért megmutatom, nekem hogy néz ki a teljes virtuális hoszt definícióm:

Ha most újraindítjuk a szervert,

A következő hibaüzenet fogad bármely PHP futtatásakor a p5414.a24.vm1 domainen

Jelzi, hogy a túloldalon az FPM még nem figyel. Így nem tudja lefuttatni a PHP szkripet.

FPM konfiguráció

A telepített PHP könyvtárában van egy "etc" mappa, abban pedig egy "php-fpm.conf.default" nevű fájl. Ez egy alap konfigurációt ad az FPM-hez "ini" szintaktikával. Ahhoz viszont, hogy figyelembe vegye az FPM, át kell másolni php-fpm.conf nevűként egy új fájlba.

Fontos, hogy megmaradjon az eredeti is érintetlenül, ha később vissza kell nyúlni valamiért, amit az élesből már töröltünk. Így NE LECSERÉLJÜK a fájlt, csak másoljuk!

Nem idézem az egész fájlt, mert nagyon hosszú. Viszont a lényeg a következő:

CTRL+W -vel ( nano szövegszerkesztőben ) keressünk rá a [www] sorra! Ez a pool neve. A hozzá tartozó beállítások ez alatt lesznek. A lényeg számunkra az elején van:

A "user" és "group" az, ahol a php felhasználóját és csoportját megadhatjuk. A "listen" meghatározza az IP-t és a portot, amin figyel. Ez az, amire a szerver beállításban hivatkoztunk. Megjegyzések nélkül a helyes beállítások a következők:

Most viszont el kell indítani az FPM-et is. A PHP könyvtárában az "sbin" könyvtárban levő "php-fpm" programot kellene lefuttatni. FIGYELEM! Csak KELLENE.

Igen, csak ennyi. Nincs "start" argumentum. Ez okozna is majd gondot, ugyanis a leállításhoz tudni kellene az FPM process azonosítóját. Viszont pid fájl használata nélkül ezt valahogy így lehetne megoldani:

Majd itt a "root" utáni számot, ami a process id-je, felhasználni a következő módon:

Ahol az 1845 nálam az azonosító volt. A PHP fordítása után viszont létrejött egy daemon szkript is, amivel ez leegyszerűsödik. Csak át kell másolnunk a php sbin könyvtárába és futattási jogot kell adni a root usernek hozzá:

Ezek után az indítás így néz ki:

A leállítás pedig:

Vagy újraindítás:

Tehát indítsuk el most az FPM-et és nézzük meg a whoami.php kimenetét! Nálam már "web" -et ír ki. A phpinfo kimenete pedig a ServerAPI mellett már az "FPM/FastCGI"-t mutatja. Remélem, mindenki hasonló sikerrel járt.

Viszont ezt a hatalmas fájlt végigpásztázni minden alkalommal, amikor bele kell nyúlni bármelyik pool-ba, nem egyszerű mulatság. Mivel a default beállítások le vannak mentve, megtehetjük a következőket:

A php-fpm.conf fájl eleje felé van egy ilyen sor:

A pontosvessző a megjegyzés jele. Tehát vegyük ki az elejéről! Ez annyit tesz, hogy az fpm.d könyvtárban beolvassa a pool definíciókat, ahogyan azt a virtuális hosztok leírásánál is hasonlóképpen mutattam. A default "www" pool-ra nem lesz szükség. Így azt teljesen töröljük ki! A törlést "nano" fájlszerkesztővel a [www] sorára állva lehet megoldani a CTRL+K billentyűkombinációt nyomva tartva, amíg el nem fogynak a sorok.

A php-fpm.conf mellett hozzuk létre az fpm.d mappát:

Majd a pool nevével megegyező névű fájlba mentsük el az első pool leírását! A pool neve legyen a virtuális hoszt neve!

A www lehetett volna a fődomain-, azaz az alap virtuális hoszt pool-ja, de azt megtartjuk arra az esetre, amikor szándékosan a mod_php modullal akarjuk a PHP-t működtetni.

A tartalma pedig:

Rendesen lecsupaszítottam a pool tartalmát. A figyelt IP-port párost tartalmazza, a felhasználót és a csoportot, valamint a "pm" és "pm.max_children" opciókat, amik kötelezőek még.

A "pm" a processzek létrehozásának és megszüntetésének módja. A "pm.max_children" pedig azt mondja meg, hány gyerekfolyamatot indíthat egyszerre maximum.

Az "ondemand" lehetőség a PHP 5.3 óta létezik. A processzeket nem hozza létre előre az induláskor, csak szükség esetén. És ha már nem kellenek, megszünteti őket

Extraként még a "listen.allowed_clients" opcióval megadtam, hogy kizárólag a 127.0.0.2 -es IP-ről fogadjon el az FPM kéréseket. Ez nem feltétlenül egyezik meg a listen után írt IP-vel, de ha 127.x.x.x IP-t választunk, akkor a remote IP is az lesz.

Ha a php.ini beállításait kellene módosítani, azt így lehet:

Végül adjuk át a dokumentum gyökeret és az összes tartalmát a web felhasználónak és csoportjának:

PHP 5.3.24

A beállítások nagyon hasonlók. Virtuális hoszt kiegészítése és új pool létrehozása kell. Valamint az init script másolása.

Virtuális hoszt konfiguráció

A p5324-es aldomainhez tartozó virtuális hoszt definíciót

kiegészítjük a <Directory> blokk előtt a következő sorral:

Újraindítjuk a szervert.

FPM konfiguráció

Másoljuk a default fájlt:

Kitöröljük a php-fpm.conf következő sora elől a pontosvesszőt.

Töröljük a [www] sorától a pool teljes tartalmát a CTRL+K billentyűkombináció segítségével.

Létrehozzuk az fpm.d mappát és a pool definíciót:

A tartalma

Majd másoljuk az init szkriptet:

Majd adjuk át a dokumentum gyökeret és az összes tartalmát a web felhasználónak és csoportjának:

PHP 5.2.17

Virtuális hoszt konfiguráció

Ez még ugyanaz, mint eddig.

A <Directory> blokk elé beszúrandó sor:

FPM konfiguráció

És most jön a neheze. Ugyanis PHP 5.2-nél még nem létezett beépített FPM. De az FPM készítői gyártottak hozzá egy patch fájlt, ami a PHP forráskódjában változtatandó sorokat tartalmazza. Ennek alkalmazására létezik a "patch" program, tehát kézzel semmit nem kell majd módosítani. A patch fájlt viszont be kell szerezni a http://php-fpm.org/downloads/ oldalról és sajnos újra kell fordítani az 5.2.17-es verziójú PHP-t. Nagy gond nincs, mert például a bemásolt php.ini nem fog eltűnni, tehát csendben újrafordul a PHP és folytatjuk a munkát.

Feltételezve, hogy a php forráskódja már ( vagy még ) ott van a "/opt/php/php-5.2.17" könyvtárban, a következőket kell tenni:

Az utolsó sor a patch alkalmazása. A balra mutató relációs jeltől jobbra a használandó fájl neve. A "-p1" pedig leveszi az első per jelet a fájlok útvonala elől a patch fájlban. Ha belenéznénk, ilyesmiket látnánk, hogy:

Az "a" jelöli az eredeti forrást. A "b" pedig a változtatottat. A többi az útvonal. Az "a" és "b" nem zavar semmit. De nekünk csak a "configure" kell "/" nélkül, mert épp a forráskód könyvtárában állunk.

A PHP telepítésénél létrehozott configure szkriptet másoljuk át "conf-php52-fpm" néven.

Írjuk hozzá a lista végére akár, vagy az --enable-fastcgi után, hogy "--enable-fpm"!

Ha a lista végére kerül, akkor az előző sor végére kell egy backslash. Ha korábban szúrjuk be, akkor pedig rögtön utána kell a backslash.

Most pedig újrafordítjuk:

Szembetűnő különbség, hogy nem egy ".default" végű fpm konfigurációs fájl jön létre, hanem rögtön "php-fpm.conf". Ezt rögtön mentsük el default-nak!

A másik szembetűnő, és egyben bosszantó is, hogy itt még nem "ini" szintaktika volt, hanem "xml". Másik konfigurációs fájl include-jára pedig nincs lehetőség. Talán ez kevésbé probléma, mivel ez a PHP verzió már elavult. És csak át nem írható, régi programok futtatására érdemes használni.

A pool definiciója a <section name="pool"> blokkban található. Minden pool ezzel kezdődik és tartalmazza blokkon belül a nevét és annak beállításait is. Ha úgy tetszik, ez a section blokk felel meg egy egyedi fájlnak az előző két PHP verziónál.

Egyetlen ilyen blokk van. Keressük meg és töröljük ki, majd a következőt írjuk a helyére:

A fenti sorokhoz egy kis magyarázat. Minden "value" blokkokból áll, amiknek van egy nevük a "name" attribútumban és egy értékük.

• name: A pool neve
• listen_address: Az IP-port páros
• allowed_clients: Azok az IP-k vesszővel elválasztva, ahonnét hajlandó kéréseket fogadni az FPM.
• user és group: A felhasználó és csoport.
• pm: A processzek tulajdonságai.
  • style: Mint az előző verzióknál a szimpla "pm" opció. De itt csak "static" és "apache-like" lehet.
  • max_children: A max gyermekfolyamatok száma
• php_defines: A PHP beállításai.
  • doc_root: Bár a ProxyPassMatch után itt is megadtuk az útvonalát a fájlnak, ezt figyelmen kívül hagyja az 5.2.17-es PHP-hez tartozó FPM. Meg kell adni a doc_root-ot, hogy ahhoz képest az url-ben kért fájlt tudja feldolgozni.
  • cgi.fix_pathinfo: Ez az opció a php.ini-ben 1-esre van állítva. Azaz helyreállítja a SCRIPT_FILENAME környezeti változóban az útvonalat. Tehát például nem kerül bele a CGI wrapper útvonala, sem pedig a proxy-ra utaló hivatkozás. Mint jelen esetben megtörténik. Ha viszont ezt bekapcsolva hagyjuk, akkor egyáltalán nem fog működni az FPM.
  • auto_prepend_file: Ez egy kis trükk lesz, ugyanis ezzel minden php program előtt lefuttathatunk egy másik PHP szkriptet, ami beállítja a $_SERVER és $_ENV változókban a SCRIPT_FILENAME értékét. Felhasználva azt az útvonalat, amit maga az FPM figyelmen kívül hagy.

Létrehozzuk a fix_pathinfo.php-t

FONTOS, hogy a végére ne tegyünk php záró címkét és a nyitó címke előtt se legyen szóköz, sortörés. Így elkerülhetjük a HTTP fejlécek akadályozását.

Jó hír, hogy ennek a verziónak a php-fpm programja már eleve ismeri a start, stop, restart argumentumokat. Valójában ez a fajta FPM egy kicsit más. Belenézve a szkriptbe, látható, hogy a php-cgi binárissal dolgozik közvetlenül. Ha elindítjuk az FPM-et:

És megnézzük a hozzá tartozó index.php-t, benne a phpinfo kimenetével, a "ServerAPI" továbbra is "CGI/FastCGI" maradt. Viszont a beállítás sikeressége leellenőrizhető azzal, ha rákeresünk az "Environment" -re és, látjuk a "web" user-t és a home könyvtárát.

Végül adjuk át a dokumentum gyökeret és az összes tartalmát a web felhasználónak és csoportjának:

Apache 2.2

Ha az 5.2-es PHP FPM-esítése nehéz volt, akkor ez hasonló lesz. Ugyanis le kell fordítani külön a mod_fastcgi modult is. Amit a www.fastcgi.com oldalról kell letölteni. Utána pedig egy ProxyPassMatch helyett FastCGIExternalServer -t fogunk használni. Ráadásként pedig egy halom nem létező dologra kell hivatkozni a virtuális hoszt beállításánál.

Modulokat viszont mást nem kell engedélyezni.

mod_fastcgi beállítása

Ezzel létre is jön a modul a modules könyvtárban és a httpd.conf -ban is engedélyezve lesz.

A "-o" és az utána levő név elhagyásával az utolsó sorban "fcgi_buf.so" néven jönne létre a modul.

Verziófüggetlen beállítások

És itt jött el a nem létezők ideje. De nézzük sorban. Elvileg a virtuális hosztokban ilyesmit is elég volna írni:

Igen, itt nem IP-t és portot, hanem socketet használunk. Útvonalként pedig a hoszt dokumentum gyökerét adjuk meg, bár más is lehetne, csak hosztonként egyedi legyen.

Az IP-s megoldás is használható volna a "-socket" helyett a "-host" paraméter megadásával. De a 2.4-es szerverben megadott porttal való ütközést el kell kerülni.
FastCGIExternalServer /dokumentumgyökér -host 127.0.0.2:9001

Igen ám, de így az összes fájlra érvényes lesz, hogy az FPM kezelje. Beleértve a html fájlokat is. Az eredménye így a html fájlok esetén egy "Access denied" üzenet lenne a tartalom helyett. Ahogy az fcgid-nél is korlátozni kellett PHP fájlokra az FPM-et, itt is ezt kellene tenni. Viszont A FastCGIExternalServer direktíva nem írható be a FilesMatch blokkba. Ami megnehezíti a megoldást és itt jön valami eszement trükközés.

A httpd.conf végére a következőt kell írni:

Itt a Location utáni "/$" egy útvonalat jelent, ami nem létezik. Nincs ilyen mappa se fájl. Mégis megmondjuk rá, hogy mindenki számára legyen tiltott a megnyitása webről. Viszont megengedjük, hogy amennyiben létezik egy REDIRECT_STATUS nevű környezeti változó, akkor hozzáférhető legyen. Ez kell a webszervernek.

Ez után egy Action sor következik, ahol egy handler és egy útvonal lenne a paraméter. A handler gyakorlatilag akármi lehetne. "kismacska" is. Csak legyen hozzárendelve a .php kiterjesztésű fájlokhoz. Egy korábbi fejezetben ezt már megtettem. De emlékeztetőül: A fenti "Location" blokk elé még kerüljön be a következő, akinél nincs ott:

Na most az Action utáni útvonal ugyanaz a nem létező útvonal, amit a Location-ben meg kellett adni. Ez is lehetne bármi hamis elérési út. De a dollár jel épp elég valószínűtlen, hogy valós url-ben szerepelne. Márpedig ezt el lehetne érni böngészőből is, ha azt le nem tiltottuk volna épp a Location blokkban.

Valójában az történik, hogy előre hivatkozunk egy nem létező útvonalra, ami valamikor létrejön a virtuális hosztokon. Persze ott is csak virtuálisan. Az Action egy bizonyos handler hatására ( amit itt kiterjesztés alapján állítottunk be ) átadja a kért fájl kezelését egy programnak. Na ez a program lesz az, amit a virtuális hoszton beállítunk. Vagyis elérjük, hogy a rendszer azt lássa, hogy az útvonalon egy program van. Aki még emlékszik a CGI wrapperekre, ott is hasonló történt. De ott a fájlok tényleg léteztek.

PHP 5.4.14

Virtuális hoszt konfiguráció

A <Directory> blokk elé most elég ennyit írni:

Itt az Alias -szal egy url-t lehet átirányítani egy, a fájlrendszeren levő útvonalra, aminek nem kell a dokumentum gyökérben lennie. Átirányítjuk egy szintén nem létező fájlra. Azért, mert a FastCGIExternalServer virtuálisan elkészíti ezt a fájlt úgy, hogy ezt írjuk első paraméterének. Majd pedig a socket útvonalát. Teljes a káosz. Tudom. De sajnos így működik.

Ez a virtuális program lehetne bármilyen útvonalon, viszont egyedinek kell lennie. Erre pedig pont alkalmas, ha a virtuális egyedi útvonalaihoz kötjük.

Szerver újraindítása

FPM konfiguráció

Az 5.4.14 -es PHP -hez kell még egy pool:

A tartalma

Érdekesség, hogy a pool nevét a $pool változóval helyettesítem be a socket fájl nevébe.

Idítsuk újra az 5.4.14-es PHP-hez tartozó FPM-et:

Fájlrendszer felhasználó és csoport beállítása

PHP 5.3.24

Virtuális hoszt konfiguráció

A <Directory> blokk elé a következő sorok kerülnek:

Szerver újraindítása

FPM konfiguráció

Az 5.3.24 -es PHP -hez kell még egy pool:

A tartalma

Az előzőhöz képest tehát csak a pool neve változott.

Indítsuk újra az 5.3.24-es PHP-hez tartozó FPM-et:

Fájlrendszer felhasználó és csoport beállítása:

PHP 5.2.17

Itt most újra az XML-lel kell dolgozni, de a nehezén már túl vagyunk.

Virtuális hoszt konfiguráció

A <Directory> blokk elé a következő sor kerül:

Szerver újraindítása

FPM konfiguráció

Az 5.2.17 -es PHP -hez kell még egy pool:

Egy új section-t vegyünk fel. Aminek a tartalma:

Nem használható a $pool változó, de cserébe nem is kell a php_defines részt megadni. Az FPM működik és a SCRIPT_FILENAME értéke is jó.

Indítsuk újra az 5.2.17-es PHP-hez tartozó FPM-et:

Fájlrendszer felhasználó és csoport beállítása:

Összegzés

Ezzel készen is vagyunk. Van tehát 3 PHP verziónk FPM-mel meghajtva, 2 Apache HTTPD webszerverrel mögöttük. A webszervereket eddig is könnyen indítottuk és állítottuk le, a PHP 5.3 és PHP 5.4 -es FPM-hez viszont a forráskönyvtárból átmásolhattuk az indító szkriptet. PHP 5.2-höz erre nem volt szükség, de az IP-port-os megoldásnál a Proxy modullal külön kellett gondoskodni a SCRIPT_FILENAME változó helyességéről.

Nyilván még ez is lehetne szebb és könnyebben kezelhető, hiszen most minden programot ( PHP, Apache, MySQL ) külön kell elindítani. Ezek kezelése viszont nem ennek a fejezetnek a témája. Később azonban szó lesz róla.

Bár a felhasználót és csoportot beállítottuk, a fájlok jogosultságait nem módosítottuk. Így az olvasási jog megmaradt a PHP fájlokra más felhasználók számára is. Tesztkörnyezetben ez nem különösebben probléma, de éles helyzetben már az. Viszont a lehetőség már megvan az olvasási jog megvonására. Illetve chroot alkalmazásával fájljogok nélkül kivédhető ez a probléma.

Bár most mindegyik virtuális hoszt a web felhasználó tulajdonában van, ez igény szerint különböző is lehetne. A pool definícióban kell megváltoztatni a felhasználót és csoportot, valamint a fájlrendszeri tulajdonosi viszonyról kell gondoskodni.

Végül mentsük el a virtuális gépet "wtk-vm1-v8-fpm" néven. v8, mert már több, mint a sima cgi megoldások, de az fpm-et még mögé írhatjuk, hogy mégis beszédesebb legyen a fájlnév. Hiszen ez egy nagyobb állomása a tesztkörnyezet elkészítésének.

Források

• Building mod_fastcgi For Apache 2
• PHP Manual: FastCGI Process Manager (FPM), hozzászólás
• Bug #24614 php as cgi always report 'No input file specified.'
• Alkalmazásonkénti chroot PHP-FPM-mel (Pásztor János)
• High-performance PHP on apache httpd 2.4.x using mod_proxy_fcgi and php-fpm.
• Module mod_fastcgi
• PHP FPM wiki: Documentation
• Re: here is an example of config for php-fpm, apache, mod_fastcgi, and a virtual host (forum.nginx.com)