Röviden: A Remi PHP-tároló aktuális PHP-verziókat szállít a Fedorához és a RHEL-családhoz, vagy modul-streamként, amely a rendszer PHP-t váltja le, vagy Software Collectionként, amely több verziót telepít párhuzamosan. A PHP2Shell-javításokat, a 8.2.35, 8.3.36, 8.4.27 és 8.5.12 verziókat ott 2026. október 22-én jelentették be. Ellenőrizze egyenként minden telepített verziót, és indítsa újra minden hozzá tartozó szolgáltatást.
Miért szerez be sok RHEL-szerver PHP-t a Remitől
A vállalati disztribúciók, mint a RHEL, az AlmaLinux és a Rocky Linux, a hosszú stabilitásra építenek. Kevés PHP-ágat szállítanak, és éveken át megtartják őket. Sok alkalmazás azonban újabb verziót igényel, mint amit a disztribúció kínál. Itt lép be Remi Collet tárolója, aki régóta a PHP csomagfelelőse a Fedora- és RHEL-környezetben.
A Remi a PHP-verziókat rövid sorrendben építi a hivatalos kiadások után. A PHP2Shellhez a tároló blogján 2026. október 22-én jelent meg egy írás a 8.2.35, 8.3.36, 8.4.27 és 8.5.12 verziókról. Ebben megnevezik a két kritikus rést, a CVE-2026-109618-at és a CVE-2026-109619-et, és sürgősen ajánlják a frissítést. A Red Hat biztonsági közleményei ezekre a csomagokra nem érvényesek; hogy a Red Hat a saját csomagjaira mit közöl, azt a RHEL, AlmaLinux és Rocky Linux: PHP-javítás ellenőrzése írás tartalmazza.
Két út: modul-stream vagy Software Collection
A Remi-blog szerint a buildek az Enterprise Linux 8-as verziójától kezdve két úton állnak rendelkezésre. Hogy a szerverén melyiket használják, az határozza meg, hogyan ellenőriz és indít újra.
| Út | Tároló | Hatás | Tipikus szolgáltatás |
|---|---|---|---|
Modul-stream, például php:remi-8.3 |
remi-modular | lecseréli a rendszer PHP-t, egy alapértelmezett verzió | php-fpm |
Software Collection, például php83 |
remi-safe | további verzió párhuzamosan saját útvonalon | verziónként saját szolgáltatás, például php83-php-fpm |
| Tesztcsomagok és kiadásjelöltek | remi-modular-test, remi-test | előzetes verziók | nem éles üzemre |
A Software Collections jellemzően az /opt/remi/phpXY alatt találhatók, a konfigurációjuk az /etc/opt/remi/phpXY alatt. Ez praktikus ahhoz, hogy régi és új alkalmazásokat üzemeltessen egy szerveren. De egyben ez a leggyakoribb oka annak, hogy egy verziót a frissítésnél figyelmen kívül hagynak.
Egy megjegyzés a parancssorhoz: a Software Collections nem állnak automatikusan rendelkezésre a php parancs alatt. A beállítástól függően a cron-feladatok és szkriptek egy saját paranccsal vagy teljes útvonallal hívják őket. Ellenőrizze ezért a crontabokat és a deployment-szkripteket is, ha tudni szeretné, melyik collectiont mire használják.
A Remi PHP-tároló ellenőrzése a PHP2Shell után
A következő parancsok kizárólag olvasnak, és megmutatják, mely Remi-csomagok vannak telepítve, és milyen állapotban.
# Aktív csomagforrások: be van kötve a remi-modular vagy a remi-safe?
dnf repolist
# Aktív modul-stream a PHP-hez
dnf module list --enabled php
# Alapcsomagok és párhuzamosan telepített Software Collections
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Minden telepített collection verziója
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
A támogatott ágaknál a helyzet egyértelmű: ha ott 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35, vagy újabb áll, a javítás benne van. A Reminél a verziószám általában az upstream verziónak felel meg, ellentétben a disztribúciós csomagokkal, amelyek gyakran megtartják a régi számukat.
A régebbi collectionökhöz, mint a php81, php80 vagy php74, nincs hivatalos célverzió. A Remi a PHP 8.1-et End-of-Life-ként kezeli. Hogy egy telepített csomag tartalmaz-e javítást a PHP2Shell ellen, a changelogban tisztázza, például az rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]" paranccsal. Találat nélkül kezelje a csomagot tisztázatlanként. Hogyan igazolhatja tisztán az ilyen találatokat, azt a CVE-számok igazolása a csomag changelogjában írás írja le.
Ne aktiválja tartósan az olyan tesztelési tárolókat, mint a remi-test vagy a remi-modular-test, éles szervereken. Kiadásjelölteket szállítanak, amelyek tesztelésre valók.
Az egyes verziók frissítése és újraindítása
Maga a frissítés a Reminél többnyire nem látványos: a dnf upgrade új csomagokat hoz a streamhez és a collectionökhöz. A kritikus rész utána következik. Minden collectionnek saját FPM-szolgáltatása van, és mindegyiket újra kell indítani.
# Az összes PHP-FPM-szolgáltatás felsorolása, a collectionökét is
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Az összes PHP-folyamat indítási idejének ellenőrzése
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
A frissítés előtti indítási idők azt jelentik: ez a szolgáltatás még régi kóddal dolgozik. Hogy az újratöltés miért nem elég, azt a PHP-FPM és az összes worker újraindítása oldal magyarázza.
Remi és a disztribúció: ki a felelős?
Aki modul-streamen keresztül átáll a Remire, a PHP-hez szállítót vált. A Red Hat, az AlmaLinux vagy a Rocky Linux biztonsági közleményei ekkor már nem a telepített PHP-csomagokra vonatkoznak. Fordítva, a Remi nem jelent problémákat a rendszer más csomagjaiban. Mindkét forrást tehát szemmel kell tartania.
Hogy egy telepített csomag honnan származik, azt a csomagadatbázis mutatja, például az rpm -qi php-fpm a gyártó és a csomagoló mezőiben. Mivel a Remi-csomagokhoz nincsenek a Red Hat értelmében vett errátak, a tároló blogja alkalmas értesítési útnak; RSS-feeddel előfizethető. A PHP2Shellnél ott a közlemény egy nappal a hivatalos kiadások után jelent meg.
A vállalatok számára ez a felosztás nem akadály, de dokumentálni kell. Rögzítse, mely szerverek szerzik be a PHP-t a Remitől, ki olvassa a közleményeket, és ki indítja újra a szolgáltatásokat egy frissítés után. Különben mindenki a másikra hagyatkozik.
Rendet tartani: kevesebb verzió, kevesebb kockázat
A Software Collections arra csábítanak, hogy a régi verziókat egyszerűen ott hagyják. A PHP2Shell után jó alkalom a rendrakásra:
- Minden collectionhöz tisztázza, melyik weboldal vagy cron-feladat használja.
- A nem használt collectionöket kapcsolja ki, és egy megfigyelési idő után távolítsa el.
- A régi collectionökön lévő alkalmazásokat emelje egy támogatott ágra.
- A megmaradó verziókat dokumentálja céllal és felelőssel.
Hogyan tartható az áttekintés sok párhuzamos verzió fölött, azt a Több PHP-verzió egy szerveren írás írja le.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük a szerverein lévő összes Remi-streamet és collectiont, és hozzárendeljük őket weboldalakhoz és cron-feladatokhoz.
- Verziónként ellenőrizzük a PHP2Shell-állapotot a csomagverzión és a changelogon keresztül.
- Telepítjük a frissítéseket, minden szolgáltatást újraindítunk, és ezt a folyamatok indítási idejével igazoljuk a PHP-javítási szolgáltatás keretében.
- A már nem szükséges collectionöket egyeztetés után ellenőrzötten eltávolítjuk.
Gyakori kérdések
Rendelkezésre bocsátotta a Remi a PHP2Shell-verziókat?
Igen. A tároló blogján 2026. október 22-én bejelentették a 8.2.35, 8.3.36, 8.4.27 és 8.5.12 verziókat, utalva a két kritikus résre, a CVE-2026-109618-ra és a CVE-2026-109619-re, és a frissítés sürgős ajánlásával.
Mi a különbség a modul-stream és az SCL között a Reminél?
Egy modul-streammel a rendszer PHP-t Remi-verzióra cseréli, ilyenkor egy PHP-verzió az alapértelmezett. A Software Collections további verziókat telepít párhuzamosan saját útvonalakra, mindegyiket saját szolgáltatással.
Kap még frissítést a PHP 8.1 a Remitől?
A Remi a PHP 8.1-et End-of-Life-ként kezeli, a PHP-projekt az ágat már nem gondozza. Hogy egy bizonyos 8.1-es csomag tartalmaz-e javítást a PHP2Shell ellen, azt a telepített csomag changelogjában ellenőrizze. Bejegyzés nélkül az állapot tisztázatlannak számít.
Egy Remi-frissítés után minden PHP-verziót újra kell indítanom?
Igen. Minden párhuzamosan telepített verziónak saját FPM-szolgáltatása van. Ha csak a fő verzió szolgáltatását indítja újra, a többi régi kóddal fut tovább.