PHP-FPM razložen: upravljalnik procesov, pooli in workerji

Na kratko: PHP-FPM (FastCGI Process Manager) poganja PHP kot samostojno storitev ob spletnem strežniku. Glavni proces (master) upravlja poole, vsak pool zažene workerje, ki zahteve obdelujejo prek FastCGI. Pooli se lahko upravljajo za vsako spletno stran z lastnim uporabnikom, lastnimi omejitvami in zaklenjenimi nastavitvami PHP. Ker workerji zaporedoma obdelajo veliko zahtev, jih je treba po posodobitvi PHP vse znova zagnati.

Kaj je PHP-FPM?

Priročnik PHP opisuje FPM kot primarno implementacijo FastCGI v PHP s funkcijami, ki so koristne predvsem za močno obremenjene spletne strani. FPM je bil v PHP 5.3.3 vključen kot samostojen SAPI, torej kot samostojen način delovanja. Njegovo ime SAPI je fpm-fcgi.

Razlika v primerjavi z mod_php: PHP ne teče v spletnem strežniku, ampak kot samostojna storitev. Nginx, Apache ali drug spletni strežnik zahteve PHP posreduje prek protokola FastCGI in prejme končni odgovor. Spletni strežnik in PHP je tako mogoče neodvisno drug od drugega znova zagnati, konfigurirati in zavarovati. Kako FastCGI deluje v osnovi, piše na strani CGI in FastCGI.

Master, pooli in workerji: procesni model

PHP-FPM sestavljajo tri ravni:

1. Glavni proces (master): prebere konfiguracijo, odpre socket in zažene ali konča workerje. Sam ne izvaja kode aplikacije.
2. Pooli: vsak pool ima ime, lasten socket ali vrata, lastnega uporabnika Unix in lastne nastavitve PHP. Priročnik izrecno navaja različne uid, gid, chroot, okolje in php.ini za vsak pool.
3. Workerji: procesi poola, ki zahteve sprejemajo in izvajajo. Worker zaporedoma obdela veliko zahtev, preden ga zamenjajo.

Koliko workerjev teče, določa upravljalnik procesov z direktivo pm:

pm.max_children v vseh načinih omejuje število hkratnih zahtev. pm.max_requests zamenja workerja po določenem številu zahtev; privzeta vrednost 0 pomeni neomejeno.

Kateri način ustreza, je odvisno od obremenitve. static vedno pripravi enako število workerjev in je primeren za enakomerno močno uporabljane aplikacije z dovolj delovnega pomnilnika. dynamic je kompromis za večino spletnih strani. ondemand prihrani pomnilnik na strežnikih z veliko majhnimi spletnimi stranmi, ker pooli brez obiskovalcev ne zasedajo workerjev; zato pa prva zahteva po premoru traja nekoliko dlje. Previsoko nastavljen pm.max_children lahko strežnik ob konicah obremenitve požene v pomanjkanje pomnilnika, prenizek povzroči čakalne čase in sporočila o napakah spletnega strežnika.

Pool z varnimi osnovnimi nastavitvami

Primer lastnega poola za vsako spletno stran z direktivami iz priročnika PHP. Poti in vrednosti so primeri:

; /etc/php/8.3/fpm/pool.d/kunde-a.conf
[kunde-a]
user = kunde-a
group = kunde-a

listen = /run/php/kunde-a.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 10s

request_terminate_timeout = 60s
security.limit_extensions = .php
clear_env = yes

php_admin_value[open_basedir] = /var/www/kunde-a:/tmp
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[error_log] = /var/log/php/kunde-a.error.log

Po priročniku je vrednosti prek php_value in php_flag mogoče med izvajanjem spremeniti z ini_set(), vrednosti prek php_admin_value in php_admin_flag pa ne. security.limit_extensions je privzeto .php .phar in določa, katere končnice datotek FPM izvede kot glavno skripto. clear_env = yes je privzeto in izprazni okolje workerjev.

Za nadzor obstajata stran s stanjem prek pm.status_path in stran ping prek ping.path. Obe naj bosta dosegljivi samo interno. Počasne zahteve FPM beleži z backtraceom, če sta nastavljena request_slowlog_timeout in slowlog.

Kakšno vlogo ima PHP-FPM pri PHP2Shell?

PHP-FPM sodi med prizadete načine delovanja. Procesni model je posebej očiten pri CVE-2026-109619: notranje stanje, ki pripada zahtevi, lahko po sprostitvi pomnilnika ostane, poznejša zahteva v istem workerju pa ga lahko uporabi, preden se ponastavi. To je mogoče samo zato, ker workerji zaporedoma obdelajo veliko zahtev.

Iz tega izhajajo tri obveznosti:

1. Namestiti posodobitev: PHP 8.5.12, 8.4.27, 8.3.36 ali 8.2.35 oziroma potrjen backport distribucije.
2. Znova zagnati vse workerje: nove datoteke na disku ne spremenijo ničesar, dokler tečejo stari workerji. To velja za vsako nameščeno različico FPM in vsak pool. Ukazi so na strani Ponovni zagon PHP-FPM in vseh workerjev.
3. Prehodne vrednosti nastaviti zaklenjeno: ukrepi php.net, na primer session.upload_progress.enabled=0, sodijo prek php_admin_value ali php_admin_flag v pool, ne v .user.ini.

Ločevanje v poole posodobitve ne nadomešča, a omejuje škodo: če vsaka spletna stran teče pod lastnim uporabnikom, napadalec po vdoru samodejno ne doseže datotek drugih. Kako to izgleda konkretno, opisuje Ločevanje poolov PHP-FPM za vsako spletno stran; vključitev v Nginx je na strani Zavarovanje Nginxa s PHP-FPM.

Kako PHP SOS pomaga konkretno?

• Zajem poolov: naštejemo vse različice FPM, poole, uporabnike in socket na vašem strežniku.
• Popravljanje in ponovni zagon: posodobimo PHP in prek časov zagona dokažemo, da ne teče več noben star worker.
• Ločevanje poolov: v okviru utrjevanja strežnika vzpostavimo za vsako spletno stran pool z lastnim uporabnikom in zaklenjenimi nastavitvami.
• Preverjanje dosegljivosti: preverimo, da socket FastCGI in strani s stanjem od zunaj niso dosegljivi.

Pogosta vprašanja

Viri

• Priročnik PHP: FastCGI Process Manager
• Priročnik PHP: konfiguracija FPM
• php.net: izdaja PHP 5.3.3
• php.net: varnostna obvestila