# mod_php izskaidrots: PHP Apache procesā > mod_php izskaidrots: kā PHP darbojas kā Apache modulis tīmekļa serverī, kā to atpazīt, kāds sakars ir prefork un .htaccess un kāpēc php.net to neiesaka. Avots: https://phpsos.de/lv/php/mod-php-erklaert/ Aktuāls uz: 25.10.2026 Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6 **Īsi:** mod_php ir PHP kā modulis Apache tīmekļa serverī. Katrs Apache process tad satur pilnu PHP interpretatoru un pats izpilda PHP kodu; SAPI saucas `apache2handler`. Tas ir viegli iestatāms, taču sasaista PHP ar Apache, parasti prasa prefork MPM un gandrīz neļauj nošķirt vietnes. PHP rokasgrāmata jaunām instalācijām no tā atrunā, un PHP2Shell gadījumā PHP komanda risku mod_php gadījumā vērtē visaugstāk. ## Kas ir mod_php? mod_php gadījumā Apache ielādē PHP kā atsevišķu moduli savos procesos. Atsevišķa PHP pakalpojuma nav: kad Apache jāpiegādā `.php` fails, to pašu PHP kodu izpilda tas pats process, kas pieņēma pieprasījumu. Daudzus gadus tas bija standarta veids, kā darbināt PHP, un vecākos serveros un dažos Docker attēlos tas ir izplatīts vēl šodien. Saskaņā ar PHP rokasgrāmatu PHP kā servera modulis konfigurāciju nolasa tikai vienreiz, startējot tīmekļa serveri. php.ini izmaiņas un moduļa atjauninājumi tāpēc stājas spēkā tikai pēc Apache pārstartēšanas. Svarīgi saprast: Apache procesi dzīvo ilgi. Process pēc kārtas pieņem daudzus savienojumus, pirms tiek nomainīts; cik daudzus, regulē Apache direktīva `MaxConnectionsPerChild`. Iegultais PHP interpretators šajā laikā paliek tas pats. Kas diskā nomaina bibliotēku `libphp`, darbojošos procesu neietekmē. Vadībai un projektu vadītājiem to var apkopot šādi: mod_php gadījumā tīmekļa serveris un PHP ir viena vienība. Kas pieskaras vienam, ietekmē otru. PHP atjauninājums nozīmē tīmekļa servera pārstartēšanu, kļūda PHP darbojas ar tīmekļa servera tiesībām, un vairāku vietņu nošķiršana vienā serverī ir gandrīz neiespējama. ## Kā mod_php tiek pieslēgts? PHP rokasgrāmata parāda pieslēgšanu divos soļos: ielādēt moduli un noteikt, kurus failus PHP jāapstrādā. ```apache LoadModule php_module modules/libphp.so SetHandler application/x-httpd-php ``` Rokasgrāmata iesaka `FilesMatch` ar `SetHandler`, nevis tikai `AddType`, lai augšupielādēti faili, piemēram, `bild.php.jpg`, netiktu izpildīti kā PHP. Debian un Ubuntu šo darbu veic pakotnes, piemēram, `libapache2-mod-php8.3`, un komandas `a2enmod` un `a2dismod`. Vai mod_php ir aktīvs, var pārbaudīt tikai lasot: ```bash apachectl -M 2>/dev/null | grep -i php # Debian/Ubuntu httpd -M 2>/dev/null | grep -i php # RHEL saime apachectl -V | grep -i mpm # aktīvais MPM (prefork, worker, event) ``` ## Prefork, Thread Safety un resursi Apache sadala pieprasījumus ar Multi-Processing moduli (MPM). Saskaņā ar PHP rokasgrāmatu mod_php nepieciešams `prefork` MPM, ja PHP nav būvēts ar Zend Thread Safety (`--enable-zts`). Lielākā daļa distributīvu pakotņu ir būvētas bez Thread Safety. Prefork nozīmē: viens process uz vienu vienlaicīgu savienojumu, un katrs process nes pilnu PHP interpretatoru. Arī pieprasījumi pēc attēliem vai CSS failiem tādējādi aizņem procesu ar PHP bagāžā. Tas maksā atmiņu un ierobežo slodzi, ko serveris var izturēt. | Pazīme | mod_php | PHP-FPM | |---|---|---| | Kur darbojas PHP? | katrā Apache procesā | atsevišķā pakalpojumā | | Apache MPM | parasti `prefork` | iespējams `event` | | Lietotājs katrai vietnei | nē, viss kā Apache lietotājs | jā, katrā pūlā | | PHP pārstartēšana | tikai kopā ar Apache | neatkarīgi no Apache | | Iestatījumi katram direktorijam | `php_value` failā `.htaccess` | pūls vai `.user.ini` | Rokasgrāmata tāpēc visām modernajām instalācijām iesaka PHP-FPM ar `mod_proxy_fcgi`: labāku resursu pārvaldību, procesu nošķiršanu, PHP pārstartēšanu bez Apache pārstartēšanas un saderību ar `event` MPM, kas kopš Apache 2.4 ir standarts. Pamatus skatiet sadaļā [PHP-FPM izskaidrots](https://phpsos.de/lv/php/php-fpm-erklaert/). ## Iestatījumi ar .htaccess, php_value un php_admin_value Ar mod_php PHP iestatījumus var iestatīt tieši Apache konfigurācijā. Rokasgrāmata atšķir izmaiņu režīmus: ieraksti ar `INI_PERDIR` drīkst atrasties php.ini, `.htaccess` vai `httpd.conf`, ieraksti ar `INI_SYSTEM` tikai php.ini vai `httpd.conf`. ```apache # VirtualHost konfigurācijā: lietojumprogrammai bloķēts php_admin_flag display_errors off php_admin_value upload_max_filesize 24M # Iespējams failā .htaccess, bet lietojumprogramma var pārrakstīt php_value max_execution_time 60 ``` `php_admin_value` un `php_admin_flag` ir atļauti tikai servera konfigurācijā, nevis `.htaccess`. Tieši šī atšķirība ir svarīga PHP2Shell pagaidu pasākumos, jo tādas vērtības kā `session.upload_progress.enabled` lietojumprogramma nedrīkst atiestatīt. ## mod_php un PHP2Shell: kāpēc risks ir visaugstākais PHP komanda PHP2Shell radīto risku mod_php gadījumā vērtē visaugstāk: tur exploit tika demonstrēts, vēl pirms tiek izpildīts lietojumprogrammas kods. Drošības spraudņi vai pārbaudes CMS tādējādi pienāk par vēlu. Turklāt mod_php gadījumā PHP darbojas ar tīmekļa servera tiesībām un tā atmiņā. Detalizētu klasifikāciju skatiet sadaļā [Kāpēc mod_php rada augstāko risku](https://phpsos.de/lv/php2shell/mod-php-risiko/). Operatoriem tāpēc ir spēkā: 1. PHP moduli atjaunināt uz 8.5.12, 8.4.27, 8.3.36 vai 8.2.35 vai apstiprinātu backport. 2. Apache pārstartēt pilnībā, ne tikai pārlādēt, un pārbaudīt procesu startēšanas laiku. 3. Pagaidu vērtības iestatīt ar `php_admin_value` servera konfigurācijā, ja atjauninājums vēl nav iespējams. 4. Pēc tam plānot pāreju uz PHP-FPM, kā aprakstīts sadaļā [Apache ar mod_php aizsardzība](https://phpsos.de/lv/server/apache-mod-php/). ## Kā PHP SOS palīdz konkrēti? - **Atpazīt:** Mēs pārbaudām, kuros serveros darbojas mod_php, ar kuru MPM un no kura pakotņu avota. - **Ielāpot:** Mēs atjauninām PHP moduli, pilnībā pārstartējam Apache un pierādām stāvokli. - **Nodrošināt pāreju:** Kur atjauninājumu kaut kas bloķē, php.net pasākumus mēs iestatām bloķētus servera konfigurācijā. - **Pārslēgt:** [Servera nostiprināšanas](https://phpsos.de/lv/leistungen/server-haertung/) ietvaros mēs testētu migrējam uz PHP-FPM ar atsevišķiem pūliem. ## Biežāk uzdotie jautājumi **Kāpēc saka mod_php, ja modulis saucas php_module?** mod_php ir sarunvalodas nosaukums PHP kā Apache modulim. Konfigurācijā to ielādē ar LoadModule; PHP rokasgrāmata kā piemēru min LoadModule php_module modules/libphp.so. Vecākas versijas izmantoja nosaukumus, piemēram, php7_module vai php5_module. **Kāpēc mod_php vajadzīgs prefork MPM?** Saskaņā ar PHP rokasgrāmatu mod_php nepieciešams prefork MPM, ja PHP nav būvēts ar Zend Thread Safety. Lielākā daļa distributīvu pakotņu ir būvētas bez Thread Safety. Prefork katram vienlaicīgam savienojumam startē savu procesu, kam vajag vairāk atmiņas. **Vai php_value rindas .htaccess darbojas arī ar PHP-FPM?** Nē. php_value un php_flag failā .htaccess ir PHP moduļa Apache direktīvas un darbojas tikai ar mod_php. Ar PHP-FPM šādi iestatījumi jāliek pūlā vai, atļautām vērtībām, failā .user.ini. **Vai man mod_php jāatsakās nekavējoties?** Vispirms nāk PHP atjauninājums ar pilnīgu Apache pārstartēšanu. Pāreja uz PHP-FPM pēc tam ir lietderīga, bet to vajag plānot un testēt. Tā PHP2Shell neaizver, jo PHP-FPM ir skarts arī. ## Avoti - [PHP rokasgrāmata: Apache 2 sistēmā Unix](https://www.php.net/manual/en/install.unix.apache2.php) - [PHP rokasgrāmata: INI izmaiņu režīmi](https://www.php.net/manual/en/configuration.changes.modes.php) - [Apache dokumentācija](https://httpd.apache.org/docs/) - [php.net: drošības paziņojumi](https://www.php.net/)