Lühidalt: Debianis ja Ubuntus unattended-upgrades-iga ning RHEL-i perekonnas dnf-automatic-uga paigaldavad Linuxi serverid turvauuendused iseseisvalt. Et uuendus ka mõjuks, peavad mõjutatud teenused nagu PHP-FPM seejärel taaskäivituma; kontrollige seda tööriistaga needrestart või protsesside käivitusaegadega. Kolmandate osapoolte allikad nagu sury.org tuleb otsesõnu vabastada, konteinereid ja põhiversioonide vahetust automaatika ei kata.
Paigast serverini: automaatika säästab aega
Kui php.net avaldas 21. oktoobril 2026 kell 16 Saksamaa aja järgi PHP2Shelli vastu paigad, algas administraatoritele võidujooks. Aruannete järgi tarnisid distributsioonid oma tagasiportimisi osaliselt samal päeval. Automaatsete turvauuendustega serverid said uued paketid paigaldada järgmisel plaanipärasel käivitusel, ilma et keegi pidanuks sekkuma.
See on hea uudis. Vähem hea: paigaldatud ei tähenda mõjuv. PHP-FPM-teenus, mis on nädalaid töötanud, jätkab vana koodiga mälus, kuni see taaskäivitatakse. Ja kolmandate osapoolte allikate paketid, konteinerid või oma PHP haldusega majutuspaneelid jäävad automaatikast sageli puutumata.
See artikkel näitab, kuidas automaatseid turvauuendusi seadistada ja täiendada nii, et need hädaolukorras tõepoolest kaitseksid.
unattended-upgrades Debianis ja Ubuntus
Ubuntus on pakett unattended-upgrades vaikimisi paigaldatud ja paigaldab turvauuendusi. Debianis paigaldate selle vajaduse korral järele. Seda juhitakse kahe failiga kaustas /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
Fail 20auto-upgrades määrab, kas ja kui sageli paketiloendeid uuendatakse ja uuendusi paigaldatakse. Väärtus on päevade arv, "1" tähendab iga päev:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Failis 50unattended-upgrades on kirjas, millistest allikatest uuendused tohivad tulla, kas pärast taaskäivitatakse ja kes teate saab. Vaikimisi on vabastatud ainult distributsiooni ametlikud turvaallikad. Ubuntu dokumentatsiooni järgi ei piisa täiendava hoidla ühendamisest: see peab olema lisaks selles loendis, muidu ignoreerib automaatika seda. See puudutab näiteks kolmanda osapoole hoidlat sury.org, mis on aruannete järgi tarninud PHP ehitusi kõigile harudele 5.6 kuni 8.5. Tausta leiate artiklist sury.org-i hoidla.
Kas kõik on õige, näitab proovikäivitus, mis midagi ei muuda:
sudo unattended-upgrade -v --dry-run
# Tegelike käivituste protokollid
ls -l /var/log/unattended-upgrades/
dnf-automatic RHEL-is, AlmaLinuxis ja Rocky Linuxis
RHEL-i perekonnas võtab sama ülesande üle dnf-automatic. Konfiguratsioon asub failis /etc/dnf/automatic.conf. Dokumentatsiooni järgi kontrollib upgrade_type = security ainult turvamärkega uuendusi ja apply_updates on vaikimisi välja lülitatud.
# /etc/dnf/automatic.conf (väljavõte)
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers 'dnf-automatic*'
Lisaks taimerile dnf-automatic.timer, mis järgib konfiguratsioonifaili, on taimereid, mis ainult teavitavad, ainult laadivad alla või paigaldavad alati. Alguses on konfiguratsioonifailiga taimer kõige arusaadavam.
Alahinnatud osa: teenuste taaskäivitamine
Paketihaldus asendab faile kettal. Töötavad protsessid säilitavad vana koodi mälus. PHP puhul tähendab see: kuni PHP-FPM või Apache mod_php-ga pole taaskäivitatud, jääb auk avatuks.
| Tööriist | Süsteem | Mida see teeb |
|---|---|---|
| needrestart | Debian, Ubuntu | tuvastab teenused aegunud failidega; Ubuntus alates 24.04 taaskäivitab need vaikimisi automaatselt |
dnf needs-restarting -s |
RHEL-i perekond | loetleb teenused, mis tuleks taaskäivitada |
Automatic-Reboot |
unattended-upgrades | taaskäivitab serveri, kui uuendus seda nõuab; vaikimisi väljas |
reboot |
dnf-automatic | never, when-changed või when-needed |
Ubuntu dokumentatsiooni järgi töötavad teenused, mis on needrestartist välja jäetud, kuni käsitsi taaskäivitamiseni vanade failidega edasi. Kontrollige seetõttu pärast iga PHP uuendust protsesside käivitusaega, nagu on kirjeldatud lehel PHP-FPM-i ja kõigi töölisprotsesside taaskäivitamine.
Tagasiportimiste puhul jääb kuvatav PHP versiooninumber sageli samaks. Paiga tõendate paketi muudatuslogi kaudu CVE-numbritega, näiteks käsuga apt-get changelog või rpm -q --changelog. Kuidas see üksikasjalikult käib, näitab Debian ja Ubuntu: kas minu PHP pakett on paigatud?.
Mida automaatika ei kata
Automaatsed uuendused on ehituskivi, mitte täielik paigahaldus. Mõned valdkonnad vajavad oma protsesse:
- Konteinerid: Dockeri kujutistes olevat PHP-d hosti uuendused ei uuenda. Ehitage kujutised uuesti, looge konteinerid uuesti.
- Majutuspaneelid: Plesk, cPanel ja sarnased paneelid haldavad PHP-d osaliselt oma pakettide ja mehhanismidega.
- Põhiversioonid: üleminek näiteks PHP 8.2-lt, mille tugi lõpeb 31.12.2026, uuemale versioonile ei toimu automaatselt.
- Rakendused: CMS-idel, pluginatel ja Composeri sõltuvustel on oma uuendusteed.
- Kontroll: keegi peab lugema automaatika protokolle ja veateateid. Vaikselt ebaõnnestuv käivitus on hullem kui mitte ühtegi, sest see teeskleb turvalisust.
Kuidas need osad ühtseks protsessiks kasvavad, kirjeldab Paigahaldus protsessina, mitte tuletõrjena.
Kokkuvõte: automaatika jah, pime usaldus ei
Automaatsed turvauuendused kuuluvad igasse internetist kättesaadavasse Linuxi serverisse. PHP2Shell näitas, kui napiks võib aeg jääda: meediaaruannete järgi täheldati esimest ründekatset juba 17. oktoobril, neli päeva enne paiku. Kes pärast seda veel käsitsi hooldusakent ootab, kaotab väärtuslikku aega.
Automaatika võtab teilt aga üle ainult paigaldamise. Teenuste taaskäivitamine, paigaseisu tõendamine, konteinerid, paneelid ja õigeaegne üleminek toetatud versioonidele jäävad ülesanneteks, mille eest peab keegi vastutama. Fikseerige see vastutus kirjalikult ja kontrollige valikuliselt, kas automaatika protokolle tõepoolest loetakse. Alles automaatika ja kontrolli kombinatsioon teeb uuendused usaldusväärseks.
Kuidas PHP SOS konkreetselt aitab?
- Seadistada: konfigureerime unattended-upgrades'i või dnf-automatic'u teie serveritele sobivaks, vabastatud kolmandate osapoolte allikad kaasa arvatud.
- Taaskäivitused kindlustada: seadistame needrestarti või vastavad kontrollid ning kontrollime pärast PHP uuendusi protsesside käivitusaegu.
- Lüngad sulgeda: konteinerid, paneelid ja põhiversioonide vahetused võtame kindlasse hooldusprotsessi.
- Kontrollida: turvahooldusleppe raames kontrollime automaatika protokolle ja teatame kõrvalekalletest.
Korduma kippuvad küsimused
Kas automaatsed uuendused ei ole tootmisserverites liiga riskantsed?
Distributsiooni turvauuendustega piiratuna on risk tavaliselt väiksem kui avatud augu oma. Need uuendused ei peaks tooma uusi funktsioone, vaid parandama vigu. Kriitiliste süsteemide juurde kuuluvad varukoopiad, seire ja testsüsteem.
Kas unattended-upgrades taaskäivitab PHP-FPM-i pärast uuendust?
Mitte tingimata ise. Ubuntus alates versioonist 24.04 taaskäivitab tööriist needrestart mõjutatud teenused vaikimisi automaatselt, kuid erandina käsitletud teenused töötavad vanade failidega edasi. Kontrollige pärast iga PHP uuendust kõigi PHP protsesside käivitusaega.
Kas sury.org-i või teiste kolmandate osapoolte allikate paketid uuendatakse automaatselt?
Ainult siis, kui vabastate allika otsesõnu. Ubuntu dokumentatsiooni järgi ei piisa hoidla lisamisest; see peab olema lisaks unattended-upgrades'i lubatud päritolude loendis.
Kas automaatika tõstab PHP 8.2 ka versioonile 8.3?
Ei. Automaatsed turvauuendused jäävad paigaldatud paketiversioonide piiresse. PHP põhiversiooni vahetus, näiteks enne PHP 8.2 toe lõppu 31.12.2026, jääb planeeritud projektiks koos testidega.
Mis on Dockeri konteineritega?
Hosti uuendused ei uuenda PHP versiooni konteinerites. Konteinerikujutised tuleb uuesti ehitada või uuesti tõmmata ning konteinerid uuesti luua.