Ukratko: Pomoću unattended-upgrades pod Debianom i Ubuntuom te dnf-automatic u RHEL obitelji Linux poslužitelji samostalno ugrađuju sigurnosna ažuriranja. Da bi ažuriranje i djelovalo, pogođene usluge poput PHP-FPM-a nakon toga se moraju ponovno pokrenuti; provjerite to pomoću needrestart ili vremena pokretanja procesa. Izvori trećih strana poput sury.org moraju se izričito odobriti, a kontejnere i promjenu glavne verzije automatika ne pokriva.
Od zakrpe do poslužitelja: automatika štedi vrijeme
Kad je php.net 21. listopada 2026. u 16 sati po njemačkom vremenu objavio zakrpe za PHP2Shell, za administratore je počela utrka. Prema izvješćima distribucije su svoje backportove dijelom isporučile još istog dana. Poslužitelji s automatskim sigurnosnim ažuriranjima mogli su nove pakete instalirati pri sljedećem planiranom pokretanju, bez ičije intervencije.
To je dobra vijest. Manje dobra: instalirano ne znači djelotvorno. PHP-FPM usluga koja radi tjednima nastavlja raditi sa starim kodom u memoriji dok se ponovno ne pokrene. A paketi iz izvora trećih strana, kontejneri ili hosting paneli s vlastitim upravljanjem PHP-om često ostaju netaknuti automatikom.
Ovaj članak pokazuje kako postaviti automatska sigurnosna ažuriranja i dopuniti ih tako da u kritičnom slučaju doista štite.
unattended-upgrades pod Debianom i Ubuntuom
Pod Ubuntuom je paket unattended-upgrades zadano instaliran i ugrađuje sigurnosna ažuriranja. Pod Debianom ga po potrebi naknadno instalirate. Upravlja se pomoću dvije datoteke pod /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
Datoteka 20auto-upgrades određuje hoće li se i koliko često osvježavati popisi paketa i ugrađivati ažuriranja. Vrijednost je broj dana, "1" znači svaki dan:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
U 50unattended-upgrades stoji iz kojih izvora ažuriranja smiju dolaziti, hoće li se nakon toga ponovno pokretati i tko dobiva obavijest. Zadano su odobreni samo službeni sigurnosni izvori distribucije. Prema dokumentaciji Ubuntua nije dovoljno uključiti dodatni repozitorij: mora uz to stajati na tom popisu, inače ga automatika ignorira. To se odnosi primjerice na repozitorij treće strane sury.org koji je prema izvješćima davao PHP buildove za sve grane od 5.6 do 8.5. Pozadina je u članku Repozitorij sury.org.
Je li sve u redu, pokazuje probno pokretanje koje ništa ne mijenja:
sudo unattended-upgrade -v --dry-run
# Zapisnici stvarnih pokretanja
ls -l /var/log/unattended-upgrades/
dnf-automatic na RHEL-u, AlmaLinuxu i Rocky Linuxu
U RHEL obitelji isti zadatak preuzima dnf-automatic. Konfiguracija se nalazi u /etc/dnf/automatic.conf. Prema dokumentaciji upgrade_type = security provjerava samo ažuriranja sa sigurnosnom napomenom, a apply_updates je zadano isključen.
# /etc/dnf/automatic.conf (izvadak)
[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*'
Uz dnf-automatic.timer, koji slijedi konfiguracijsku datoteku, postoje timeri koji samo javljaju, samo preuzimaju ili uvijek instaliraju. Za početak je timer s konfiguracijskom datotekom najrazumljiviji.
Podcijenjeni dio: ponovno pokretanje usluga
Upravitelj paketa zamjenjuje datoteke na disku. Pokrenuti procesi zadržavaju stari kod u memoriji. Kod PHP-a to znači: dok se PHP-FPM ili Apache s mod_php-om ne pokrenu ponovno, ranjivost ostaje otvorena.
| Alat | Sustav | Što radi |
|---|---|---|
| needrestart | Debian, Ubuntu | prepoznaje usluge sa zastarjelim datotekama; pod Ubuntuom od 24.04 zadano ih automatski ponovno pokreće |
dnf needs-restarting -s |
RHEL obitelj | ispisuje usluge koje bi trebalo ponovno pokrenuti |
Automatic-Reboot |
unattended-upgrades | ponovno pokreće poslužitelj ako ažuriranje to traži; zadano isključeno |
reboot |
dnf-automatic | never, when-changed ili when-needed |
Prema dokumentaciji Ubuntua usluge koje needrestart izuzima nastavljaju raditi sa starim datotekama do ručnog ponovnog pokretanja. Zato nakon svakog PHP ažuriranja provjerite vrijeme pokretanja procesa, kako je opisano u članku Ponovno pokrenuti PHP-FPM i sve workere.
Kod backportova prikazani broj verzije PHP-a često ostaje isti. Zakrpu dokazujete putem changeloga paketa s CVE brojevima, primjerice pomoću apt-get changelog ili rpm -q --changelog. Kako to ide u pojedinostima, pokazuje članak Debian i Ubuntu: je li moj PHP paket zakrpan?.
Što automatika ne pokriva
Automatska ažuriranja su jedan gradivni element, a ne potpuno upravljanje zakrpama. Neka područja trebaju vlastite postupke:
- Kontejneri: PHP u Docker image-ima ne ažuriraju se ažuriranjima hosta. Image-e ponovno izgraditi, kontejnere ponovno izraditi.
- Hosting paneli: Plesk, cPanel i slični paneli djelomično upravljaju PHP-om putem vlastitih paketa i mehanizama.
- Glavne verzije: prelazak primjerice s PHP-a 8.2, koji 31. 12. 2026. dosiže kraj podrške, na noviju verziju ne događa se automatski.
- Aplikacije: CMS-ovi, dodaci i Composer ovisnosti imaju vlastite putove ažuriranja.
- Kontrola: netko mora čitati zapisnike i poruke o pogreškama automatike. Tiho propadajuće pokretanje gore je od nikakvog jer simulira sigurnost.
Kako se ti dijelovi spajaju u proces, opisuje članak Upravljanje zakrpama kao proces umjesto gašenja požara.
Zaključak: automatika da, slijepo povjerenje ne
Automatska sigurnosna ažuriranja pripadaju na svaki Linux poslužitelj dostupan s interneta. PHP2Shell je pokazao koliko vrijeme može postati kratko: prema medijskim izvješćima prvi pokušaj napada opažen je već 17. listopada, četiri dana prije zakrpa. Tko je nakon toga još čekao ručni prozor za održavanje, gubio je dragocjeno vrijeme.
Automatika Vam ipak skida samo ugrađivanje. Ponovno pokretanje usluga, dokaz stanja zakrpa, kontejneri, paneli i pravodobni prelazak na podržane verzije ostaju zadaće za koje netko mora biti zadužen. Tu zaduženost utvrdite pisano i uzorkom provjerite čitaju li se zapisnici automatike doista. Tek kombinacija automatike i kontrole čini ažuriranja pouzdanima.
Kako PHP SOS konkretno pomaže?
- Postaviti: konfiguriramo unattended-upgrades ili dnf-automatic prema Vašim poslužiteljima, uključujući odobrene izvore trećih strana.
- Osigurati ponovna pokretanja: postavljamo needrestart ili odgovarajuće provjere i nakon PHP ažuriranja kontroliramo vrijeme pokretanja procesa.
- Zatvoriti praznine: kontejnere, panele i promjene glavnih verzija uključujemo u čvrst tijek održavanja.
- Kontrolirati: u sigurnosnom ugovoru o održavanju provjeravamo zapisnike automatike i javljamo neobičnosti.
Česta pitanja
Nisu li automatska ažuriranja na produkcijskim poslužiteljima preriskantna?
Ograničen na sigurnosna ažuriranja distribucije, rizik je obično manji od rizika otvorene ranjivosti. Ta ažuriranja ne bi trebala donositi nove funkcije, nego otklanjati pogreške. Za kritične sustave pripadaju sigurnosne kopije, nadzor i testni sustav.
Ponovno pokreće li unattended-upgrades PHP-FPM nakon ažuriranja?
Ne nužno sam. Pod Ubuntuom od verzije 24.04 alat needrestart zadano automatski ponovno pokreće pogođene usluge, ali izuzete usluge nastavljaju raditi sa starim datotekama. Nakon svakog PHP ažuriranja provjerite vrijeme pokretanja svih PHP procesa.
Ažuriraju li se paketi iz sury.org ili drugih izvora trećih strana automatski?
Samo ako izvor izričito odobrite. Prema dokumentaciji Ubuntua nije dovoljno dodati repozitorij; mora uz to stajati na popisu dopuštenih podrijetla unattended-upgrades.
Podiže li automatika i PHP 8.2 na 8.3?
Ne. Automatska sigurnosna ažuriranja ostaju unutar instaliranih verzija paketa. Promjena glavne verzije PHP-a, primjerice prije kraja podrške za PHP 8.2 31. 12. 2026., ostaje planirani projekt s testovima.
Što je s Docker kontejnerima?
Ažuriranja na hostu ne ažuriraju verziju PHP-a u kontejnerima. Image-i kontejnera moraju se ponovno izgraditi ili ponovno povući, a kontejneri ponovno izraditi.