Remi saugykla: PHP RHEL sistemose išlaikyti aktualų

Trumpai: Remi PHP saugykla teikia aktualias PHP versijas Fedora ir RHEL šeimai, arba kaip modulio srautą, kuris pakeičia sistemos PHP, arba kaip Software Collection, diegiančią kelias versijas lygiagrečiai. PHP2Shell taisymai 8.2.35, 8.3.36, 8.4.27 ir 8.5.12 ten paskelbti 2026 m. spalio 22 d. Kiekvieną įdiegtą versiją tikrinkite atskirai ir iš naujo paleiskite kiekvieną atitinkamą paslaugą.

Kodėl tiek daug RHEL serverių PHP gauna iš Remi

Įmonių distribucijos, tokios kaip RHEL, AlmaLinux ir Rocky Linux, remiasi ilgalaike stabilumu. Jos teikia nedaug PHP šakų ir išlaiko jas metų metus. Bet daugelis programų reikalauja naujesnių versijų, nei distribucija siūlo. Čia įsijungia Remi Collet saugykla, ilgametis PHP paketų prižiūrėtojas Fedora ir RHEL aplinkoje.

Remi PHP versijas sukuria netrukus po oficialių leidimų. Dėl PHP2Shell saugyklos tinklaraštyje 2026 m. spalio 22 d. pasirodė straipsnis apie versijas 8.2.35, 8.3.36, 8.4.27 ir 8.5.12. Jame minimos abi kritinės spragos CVE-2026-109618 ir CVE-2026-109619 ir skubiai rekomenduojama atnaujinti. Red Hat saugumo pranešimai šiems paketams negalioja; ką Red Hat praneša savo paketams, rašoma straipsnyje RHEL, AlmaLinux ir Rocky Linux: PHP pataisos patikra.

Du keliai: modulio srautas arba Software Collection

Pasak Remi tinklaraščio, kūriniai Enterprise Linux nuo 8 versijos prieinami dviem keliais. Kuris jūsų serveryje naudojamas, lemia, kaip tikrinate ir paleidžiate iš naujo.

Software Collections paprastai yra aplanke /opt/remi/phpXY, jų konfigūracija /etc/opt/remi/phpXY. Tai praktiška, norint viename serveryje eksploatuoti senas ir naujas programas. Bet tai ir dažniausia priežastis, kodėl atnaujinant versija praleidžiama.

Pastaba dėl komandinės eilutės: Software Collections automatiškai nėra prieinamos komanda php. Priklausomai nuo sąrankos, cron užduotys ir scenarijai jas iškviečia atskira komanda arba pilnu keliu. Todėl patikrinkite ir crontab bei diegimo scenarijus, jei norite žinoti, kuri collection kam naudojama.

Remi PHP saugyklos patikra po PHP2Shell

Toliau pateiktos komandos tik skaito ir rodo, kurie Remi paketai įdiegti ir kokia jų būsena.

# Aktyvūs paketų šaltiniai: ar prijungtas remi-modular arba remi-safe?
dnf repolist

# Aktyvus PHP modulio srautas
dnf module list --enabled php

# Baziniai paketai ir lygiagrečiai įdiegtos Software Collections
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort

# Kiekvienos įdiegtos collection versija
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done

Palaikomose šakose padėtis aiški: jei ten 8.5.12, 8.4.27, 8.3.36 ar 8.2.35 arba naujesnė, taisymas yra. Pas Remi versijos numeris paprastai atitinka upstream versiją, skirtingai nei distribucijų paketuose, kurie dažnai išlaiko seną numerį.

Senesnėms collection, tokioms kaip php81, php80 ar php74, oficialios tikslinės versijos nėra. Remi PHP 8.1 nurodo kaip End-of-Life. Ar įdiegtas paketas turi taisymą nuo PHP2Shell, išsiaiškinkite pakeitimų žurnale, pavyzdžiui, su rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Be radinių paketą laikykite neišaiškintu. Kaip tokius radinius tvarkingai įrodyti, aprašo straipsnis CVE numerių įrodymas paketo pakeitimų žurnale.

Kiekvienos versijos atnaujinimas ir paleidimas iš naujo

Pats atnaujinimas pas Remi paprastai neįdomus: dnf upgrade atsineša naujus srauto ir collection paketus. Kritinė dalis seka po to. Kiekviena collection turi savo FPM paslaugą, ir kiekvieną reikia paleisti iš naujo.

# Išvardyti visas PHP-FPM paslaugas, taip pat collection
systemctl list-units --type=service --all | grep -E "php.*fpm"

# Patikrinti visų PHP procesų paleidimo laiką
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"

Paleidimo laikai prieš atnaujinimą reiškia: ši paslauga vis dar dirba su senu kodu. Kodėl perkrovimo nepakanka, paaiškina skyrelis PHP-FPM ir visų worker paleidimas iš naujo.

Remi ir distribucija: kas atsakingas?

Kas per modulio srautą pereina prie Remi, PHP atžvilgiu keičia tiekėją. Red Hat, AlmaLinux ar Rocky Linux saugumo pranešimai tada nebesusiję su įdiegtais PHP paketais. Atvirkščiai, Remi nepraneša apie problemas kituose sistemos paketuose. Todėl abu šaltinius turite laikyti akiratyje.

Iš kur įdiegtas paketas, parodo paketų duomenų bazė, pavyzdžiui, su rpm -qi php-fpm laukuose apie gamintoją ir paketuotoją. Kadangi Remi paketams Red Hat prasme errata nėra, saugyklos tinklaraštis tinka kaip pranešimų kelias; jį galima prenumeruoti per RSS. Su PHP2Shell pranešimas ten pasirodė dieną po oficialių leidimų.

Įmonėms šis pasiskirstymas nėra kliūtis, bet jis turi būti dokumentuotas. Užfiksuokite, kurie serveriai PHP gauna iš Remi, kas skaito pranešimus ir kas po atnaujinimo iš naujo paleidžia paslaugas. Kitaip kiekvienas pasikliauja kitu.

Palaikyti tvarką: mažiau versijų, mažiau rizikos

Software Collections skatina senas versijas tiesiog palikti. Po PHP2Shell tai geras laikas sutvarkyti:

1. Kiekvienai collection išsiaiškinti, kuri svetainė ar cron užduotis ją naudoja.
2. Nenaudojamas collection išjungti ir po stebėjimo laikotarpio pašalinti.
3. Programas senose collection perkelti į palaikomą šaką.
4. Likusias versijas dokumentuoti su paskirtimi ir atsakingu asmeniu.

Kaip išlaikyti apžvalgą daugelio lygiagrečių versijų atveju, aprašo straipsnis Kelios PHP versijos viename serveryje.

Kaip PHP SOS padeda konkrečiai?

• Surašome visus Remi srautus ir collection jūsų serveriuose ir priskiriame juos svetainėms bei cron užduotims.
• PHP2Shell būseną kiekvienai versijai tikriname per paketo versiją ir pakeitimų žurnalą.
• Įdiegiame atnaujinimus, iš naujo paleidžiame kiekvieną paslaugą ir tai įrodome procesų paleidimo laikais pagal PHP pataisų paslaugą.
• Nebereikalingas collection suderinę kontroliuojamai pašaliname.

Dažni klausimai

Šaltiniai

• Remi's RPM repository: tinklaraštis
• Red Hat Security Bulletin RHSB-2026-013
• php.net: palaikomos versijos