Mitu PHP versiooni ühes serveris: paigake igaüks eraldi

Lühidalt: Kui serveris töötab mitu PHP versiooni, tuleb pärast PHP2Shelli igaüks eraldi kontrollida, uuendada ja taaskäivitada. Tüüpilised allikad on operatsioonisüsteem, majutuspaneelid nagu Plesk või cPanel, kolmandad allikad nagu sury.org või Remi, CloudLinux, LiteSpeed ja ise kompileeritud versioonid. Alles pakettidest, failidest ja töötavatest protsessidest koostatud täielik nimekiri näitab, et ühtegi versiooni ei ole tõesti märkamata jäetud.

Unustatud versioon

Server, mis on töötanud mõned aastad, koguneb PHP versioone nagu pööning vanu mööblieset. Paneel tõi kaasa kolm haru, ühe kliendi jaoks lisandus vanem versioon kolmandast allikast, operatsioonisüsteemil on oma. Kõik need paigaldati kunagi heast põhjusest. Aga täna ei tea keegi enam, milliseid veel vaja on.

Pärast PHP2Shelli on just see probleem. Parandused ilmusid 21. oktoobril 2026 versioonidele PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Iga serveris olev paigaldus saab need aga oma teed pidi, oma paketi hooldajalt ja omal ajal. PHP 8.1 ja vanemate jaoks on olemas ainult minimaalsed lähtekoodi backportid. Kes uuendab ainult põhiversiooni, jätab teised lahtiseks.

Kust need paljud versioonid tulevad

Allolev ülevaade nimetab tüüpilisi allikaid ja näiteteid. Täpsed teed erinevad versiooni ja distributsiooni järgi.

Eriti salakavalad on sury.org paketid, sest need kasutavad samu teid nagu distributsioon. Kas php8.3 pärineb Debianist või sury.org-ist, näitab alles paketiallikas. Eripärasid kirjeldavad artiklid sury.org hoidla ja Remi hoidla. Kuidas Plesk oma versioone haldab, kirjeldab leht Plesk-server: PHP versioonide kontroll ja paikamine.

Kõikide PHP paigalduste leidmine

Usaldusväärne nimekiri tekib kolmest vaatenurgast. Käsud on puhtalt lugevad ja võivad olenevalt serverist töötada mõnda aega.

# 1. Paketid: mida paketihaldus teab
dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp"
rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort

# 2. Failid: käivitatavad PHP binaarid, ka väljaspool paketihaldust
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null

# 3. Protsessid: mis tegelikult parajasti töötab, koos käivitusajaga
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"

Võrrelge kolme nimekirja. Fail ilma paketita viitab ise kompileeritud või käsitsi kopeeritud versioonile. Protsess ilma sobiva failita võib viidata kustutatud, kuid veel töötavale paigaldusele. Apache'i puhul kontrollige lisaks, kas PHP moodul on laaditud, näiteks käsuga apache2ctl -M või httpd -M. Konteinerid ja Kubernetes'i podid ilmuvad nendes nimekirjades ainult osaliselt ja vajavad piltide eraldi kontrolli.

Iga versiooni eraldi paikamine

Kui igal paigaldusel on teie nimekirjas rida, järgneb igaühele sama protsess:

1. Selgitage vastutus: Kas paik tuleb distributsioonilt, paneelilt, kolmandast allikast või teilt endalt?
2. Hinnake seisu: ametlik parandatud versioon, kinnitatud backport, selgitamata või lahtine.
3. Uuendage: vastava allika kaudu, mitte mõne muu kaudu.
4. Taaskäivitage: selle versiooni teenus, mitte ainult põhiteenus. mod_php puhul veebiserver. Üksikasjad on lehel PHP-FPM ja kõigi tööprotsesside taaskäivitus.
5. Kontrollige: võrrelge protsesside käivitusaega uuenduse ajahetkega.
6. Dokumenteerige: versioon, paketi seis, tõend, taaskäivituse aeg.

Versioonide puhul, mille jaoks paika ei ole, kehtivad kuni üleminekuni php.net-i vahemeetmed. Rakendage neid iga versiooni jaoks eraldi, sest igal paigaldusel on oma php.ini ja omad poolid.

Millist versiooni kasutab käsurida, millist konteiner?

Kaks valdkonda jäävad otsingu sõelale eriti sageli kinni. Esimene on käsurida. Debianis ja Ubuntus otsustab alternatiivide süsteem, milline binaar käsu php taga on. update-alternatives --display php näitab, millised versioonid on registreeritud ja milline parajasti kehtib. Cron-tööd, mis kutsuvad fikseeritud teed nagu /usr/bin/php7.4, lähevad sellest sättest siiski mööda. Seetõttu tasub vaadata kõigi kasutajate crontabe ja paneelide seadistust, mis loovad oma cron-töid.

Teine valdkond on konteinerid. Serveris olev Docker-konteiner toob kaasa oma PHP versiooni, mis ei ilmu hosti ühelgi paketinimekirjas. docker ps näitab töötavaid konteinereid; kas PHP on neis olemas ja millises versioonis, selgub pildi vaatamisest või käsust php -v konteineris. Paik ei tehta seal hostis, vaid pildi uuesti ehitamise ja konteineri väljavahetamisega.

Vähem on turvalisem

Parim kontroll on see, mida pole vaja teha. Iga paigaldatud PHP versioon kahekordistab töö järgmise turvaaugu korral. Pärast PHP2Shelli tasub seetõttu kehtestada selge reegel: iga serveri versioon vajab eesmärki ja vastutajat. Mis neid ei oma, deaktiveeritakse esmalt ja eemaldatakse pärast vaatlusaega. Lähemalt artiklis Vanade PHP versioonide väljalülitamine majutuspaneelis.

Kuidas PHP SOS konkreetselt aitab?

• Koostame teie serveritele täieliku nimekirja kõigist PHP paigaldustest pakettide, failide, protsesside ja konteinerite põhjal.
• Selgitame iga versiooni kohta päritolu, vastutuse ja paigatud seisu.
• PHP-paigateenuse raames uuendame iga versiooni, taaskäivitame iga teenuse ja tõendame seisu.
• Koos teiega otsustame, millised versioonid jäävad, ja eemaldame ülejäänud kontrollitult.

Korduma kippuvad küsimused

Allikad

• php.net: turvateated
• php.net: toetatud versioonid
• Red Hat Security Bulletin RHSB-2026-013