# mod_php selgitus: PHP Apache'i protsessis

> mod_php selgitatud: kuidas PHP töötab Apache'i moodulina veebiserveris, kuidas seda ära tunda, mis pistmist on prefork'il ja .htaccess'il ning miks php.net ei soovita.

Allikas: https://phpsos.de/et/php/mod-php-erklaert/  
Seis: 25.10.2026  
Pakkuja: PHP SOS, PHP hädaabi ja serveri turvalisus. Kohene abi WhatsAppis: https://wa.me/491736494914?text=Tere%2C%20PHP%20SOS%2C%20vajame%20abi%20oma%20PHP-serveriga.%20Ettev%C3%B5te%3A%20%E2%80%A6%20Veebisait%3A%20%E2%80%A6

**Lühidalt:** mod_php on PHP moodulina Apache'i veebiserveris. Iga Apache'i protsess sisaldab siis täielikku PHP interpretaatorit ja käivitab PHP koodi ise; SAPI nimi on `apache2handler`. Seda on lihtne seadistada, kuid see seob PHP Apache'iga, nõuab enamasti prefork-MPM-i ja võimaldab veebisaitide vahel vaevalt eraldamist. PHP käsiraamat ei soovita seda uute paigalduste jaoks ja PHP2Shelli puhul hindab PHP meeskond riski mod_php korral kõige suuremaks.

## Mis on mod_php?

mod_php puhul laadib Apache PHP oma protsessidesse eraldi moodulina. Eraldi PHP teenust ei ole: kui Apache peab `.php` faili edastama, käivitab PHP koodi sama protsess, mis päringu vastu võttis. Aastaid oli see PHP käitamise tavaline viis ja see on vanemates serverites ning mõnes Dockeri kujutises tänaseni levinud.

PHP käsiraamatu järgi loeb PHP servermoodulina oma seadistuse ainult ühe korra, veebiserveri käivitamisel. Muudatused php.ini-s ja mooduli uuendused hakkavad seetõttu mõjuma alles pärast Apache'i taaskäivitust.

Mõistmiseks on oluline: Apache'i protsessid elavad kaua. Üks protsess võtab järjest vastu palju ühendusi, enne kui see asendatakse; mitu, reguleerib Apache'i direktiiv `MaxConnectionsPerChild`. Põimitud PHP interpretaator jääb selle aja jooksul samaks. Kes asendab kettal teegi `libphp`, ei muuda töötavates protsessides midagi.

Juhtkonnale ja projektijuhtidele saab seda kokku võtta nii: mod_php puhul on veebiserver ja PHP üks tervik. Kes ühte puudutab, mõjutab teist. PHP uuendus tähendab veebiserveri taaskäivitust, PHP viga töötab veebiserveri õigustega ja mitme veebisaidi eraldamine samas serveris on vaevalt võimalik.

## Kuidas mod_php seotakse?

PHP käsiraamat näitab sidumist kahes sammus: moodul laadida ja määrata, milliseid faile PHP töötlema peab.

```apache
LoadModule php_module modules/libphp.so

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>
```

Käsiraamat soovitab `FilesMatch` koos `SetHandler`-iga mitte ainult `AddType` asemel, et üleslaaditud faile nagu `bild.php.jpg` ei käivitataks PHP-na. Debianis ja Ubuntus võtavad selle töö üle paketid nagu `libapache2-mod-php8.3` ning käsud `a2enmod` ja `a2dismod`.

Kas mod_php on aktiivne, saab lugevalt kontrollida:

```bash
apachectl -M 2>/dev/null | grep -i php    # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php        # RHEL-i perekond
apachectl -V | grep -i mpm               # aktiivne MPM (prefork, worker, event)
```

## Prefork, Thread Safety ja ressursid

Apache jaotab päringuid multitöötlusmooduli (MPM) kaudu. PHP käsiraamatu järgi vajab mod_php `prefork`-MPM-i, kui PHP-d ei ole ehitatud Zend Thread Safety'ga (`--enable-zts`). Enamik distributsioonide pakette on ehitatud ilma Thread Safety'ta.

Prefork tähendab: üks protsess samaaegse ühenduse kohta ja iga protsess kannab täielikku PHP interpretaatorit. Ka piltide või CSS-failide päringud hõivavad seega protsessi, millel on PHP kaasas. See maksab mälu ja piirab koormust, mida server kannab.

| Tunnus | mod_php | PHP-FPM |
|---|---|---|
| Kus PHP töötab? | igas Apache'i protsessis | eraldi teenuses |
| Apache MPM | enamasti `prefork` | `event` võimalik |
| Kasutaja veebisaidi kohta | ei, kõik Apache'i kasutajana | jah, pooli kohta |
| PHP taaskäivitamine | ainult koos Apache'iga | Apache'ist sõltumatu |
| Sätted kataloogi kohta | `php_value` failis `.htaccess` | pool või `.user.ini` |

Käsiraamat soovitab seetõttu kõigi kaasaegsete paigalduste jaoks PHP-FPM-i koos `mod_proxy_fcgi`-ga: parem ressursihaldus, protsesside eraldamine, PHP taaskäivitamine ilma Apache'i taaskäivituseta ja ühilduvus `event`-MPM-iga, mis on alates Apache 2.4-st vaikeväärtus. Alused leiate lehelt [PHP-FPM selgitus](https://phpsos.de/et/php/php-fpm-erklaert/).

## Sätted failidega .htaccess, php_value ja php_admin_value

mod_php-ga saab PHP sätteid seada otse Apache'i seadistuses. Käsiraamat eristab seejuures muutmisrežiime: kirjed `INI_PERDIR` tohivad olla failides php.ini, `.htaccess` või `httpd.conf`, kirjed `INI_SYSTEM` ainult failides php.ini või `httpd.conf`.

```apache
# VirtualHosti seadistuses: rakenduse jaoks lukustatud
php_admin_flag  display_errors off
php_admin_value upload_max_filesize 24M

# Failis .htaccess võimalik, kuid rakendus võib üle kirjutada
php_value max_execution_time 60
```

`php_admin_value` ja `php_admin_flag` on lubatud ainult serveri seadistuses, mitte failis `.htaccess`. Just see vahe on PHP2Shelli ajutiste meetmete puhul oluline, sest väärtusi nagu `session.upload_progress.enabled` ei tohi rakendus tagasi lähtestada.

## mod_php ja PHP2Shell: miks risk on kõige suurem

PHP meeskond hindab PHP2Shelli riski mod_php puhul kõige suuremaks: seal näidati ekspluateerimist enne, kui rakenduse kood üldse käivitub. Turvapistikprogrammid või CMS-i kontrollid tulevad seega liiga hilja. Lisaks töötab PHP mod_php puhul veebiserveri õiguste ja mäluga. Üksikasjaliku hinnangu leiate lehelt [Miks mod_php kannab suurimat riski](https://phpsos.de/et/php2shell/mod-php-risiko/).

Käitajatele kehtib seetõttu:

1. Uuendage PHP moodul versioonile 8.5.12, 8.4.27, 8.3.36 või 8.2.35 või kinnitatud backportile.
2. Käivitage Apache täielikult uuesti, mitte ainult ei laadige seadistust uuesti, ja kontrollige protsesside käivitusaega.
3. Seadke üleminekuväärtused `php_admin_value` kaudu serveri seadistuses, kui uuendus ei ole veel võimalik.
4. Seejärel planeerige üleminek PHP-FPM-ile, nagu on kirjeldatud lehel [Apache'i mod_php kaitsmine](https://phpsos.de/et/server/apache-mod-php/).

## Kuidas PHP SOS konkreetselt aitab?

- **Tuvastamine:** Kontrollime, millistes serverites mod_php töötab, millise MPM-iga ja millisest paketiallikast.
- **Paikamine:** Uuendame PHP moodulit, käivitame Apache'i täielikult uuesti ja tõendame seisu.
- **Ülemineku kaitsmine:** Kus uuendus on blokeeritud, seame php.net-i meetmed lukustatult serveri seadistusse.
- **Ümberlülitamine:** [Serveri karastamise](https://phpsos.de/et/leistungen/server-haertung/) raames migreerime testituna PHP-FPM-ile oma poolidega.


## Korduma kippuvad küsimused

**Miks öeldakse mod_php, kui moodul kannab nime php_module?**  
mod_php on argikeelne nimi PHP-le Apache'i moodulina. Seadistuses laaditakse see käsuga LoadModule; PHP käsiraamat toob näiteks LoadModule php_module modules/libphp.so. Vanemad versioonid kasutasid nimesid nagu php7_module või php5_module.

**Miks mod_php vajab prefork-MPM-i?**  
PHP käsiraamatu järgi vajab mod_php prefork-MPM-i, kui PHP-d ei ole ehitatud Zend Thread Safety'ga. Enamik distributsioonide pakette on ehitatud ilma Thread Safety'ta. Prefork käivitab iga samaaegse ühenduse jaoks oma protsessi, mis vajab rohkem mälu.

**Kas php_value read failis .htaccess töötavad ka PHP-FPM-iga?**  
Ei. php_value ja php_flag failis .htaccess on PHP mooduli Apache'i direktiivid ja mõjuvad ainult mod_php-ga. PHP-FPM-i all kuuluvad sellised sätted pooli või lubatud väärtuste jaoks faili .user.ini.

**Kas pean mod_php-st kohe loobuma?**  
Esmalt tuleb PHP uuendus koos Apache'i täieliku taaskäivitusega. Üleminek PHP-FPM-ile on seejärel mõistlik, kuid seda tuleks planeerida ja testida. See ei sulge PHP2Shelli, sest PHP-FPM on samuti mõjutatud.

## Allikad

- [PHP käsiraamat: Apache 2 Unixis](https://www.php.net/manual/en/install.unix.apache2.php)
- [PHP käsiraamat: INI muutmisrežiimid](https://www.php.net/manual/en/configuration.changes.modes.php)
- [Apache'i dokumentatsioon](https://httpd.apache.org/docs/)
- [php.net: turvateated](https://www.php.net/)