Pe scurt: Cu unattended-upgrades sub Debian și Ubuntu, precum și cu dnf-automatic în familia RHEL, serverele Linux aplică singure actualizările de securitate. Pentru ca o actualizare să și acționeze, serviciile afectate, precum PHP-FPM, trebuie repornite după aceea; verificați asta cu needrestart sau cu momentele de pornire ale proceselor. Sursele terțe, precum sury.org, trebuie permise explicit, iar containerele și schimbările de versiune principală nu sunt acoperite de automatizare.
De la patch la server: automatizarea câștigă timp
Când php.net a publicat, la 21 octombrie 2026, la ora 16:00, ora Germaniei, patchurile împotriva PHP2Shell, pentru administratori a început o cursă. Potrivit rapoartelor, distribuțiile și-au livrat backporturile parțial în aceeași zi. Serverele cu actualizări automate de securitate au putut instala noile pachete la următoarea rulare planificată, fără ca cineva să trebuiască să intervină.
Aceasta este vestea bună. Cea mai puțin bună: instalat nu înseamnă eficient. Un serviciu PHP-FPM care rulează de săptămâni continuă să lucreze cu vechiul cod din memorie până este repornit. Iar pachetele din surse terțe, containerele sau panourile de hosting cu administrare proprie a PHP rămân adesea neatinse de automatizare.
Acest articol arată cum configurați actualizările automate de securitate și cum le completați astfel încât să protejeze cu adevărat în caz de urgență.
unattended-upgrades sub Debian și Ubuntu
Sub Ubuntu, pachetul unattended-upgrades este instalat implicit și aplică actualizările de securitate. Sub Debian îl instalați la nevoie. Este controlat prin două fișiere din /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
Fișierul 20auto-upgrades stabilește dacă și cât de des sunt actualizate listele de pachete și aplicate actualizările. Valoarea este numărul de zile, "1" înseamnă zilnic:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
În 50unattended-upgrades se află din ce surse au voie să vină actualizări, dacă se repornește după aceea și cine primește un mesaj. Implicit sunt permise doar sursele oficiale de securitate ale distribuției. Potrivit documentației Ubuntu, nu este suficient să includeți un alt depozit: el trebuie să figureze suplimentar în această listă, altfel este ignorat de automatizare. Aceasta privește, de exemplu, depozitul terț sury.org, care, potrivit rapoartelor, a pus la dispoziție build-uri PHP pentru toate ramurile de la 5.6 la 8.5. Contextul se găsește în articolul Depozitul sury.org.
Dacă totul este în regulă arată o rulare de probă, care nu modifică nimic:
sudo unattended-upgrade -v --dry-run
# Jurnalele rulărilor reale
ls -l /var/log/unattended-upgrades/
dnf-automatic pe RHEL, AlmaLinux și Rocky Linux
În familia RHEL, dnf-automatic preia aceeași sarcină. Configurația se află în /etc/dnf/automatic.conf. Potrivit documentației, upgrade_type = security verifică doar actualizările cu indicație de securitate, iar apply_updates este implicit dezactivat.
# /etc/dnf/automatic.conf (extras)
[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*'
Pe lângă dnf-automatic.timer, care urmează fișierul de configurare, există timere care doar raportează, doar descarcă sau instalează întotdeauna. Pentru început, timerul cu fișier de configurare este cel mai ușor de urmărit.
Partea subestimată: repornirea serviciilor
Managerul de pachete înlocuiește fișiere pe disc. Procesele în execuție păstrează vechiul cod în memorie. La PHP aceasta înseamnă: atâta timp cât PHP-FPM sau Apache cu mod_php nu sunt repornite, vulnerabilitatea rămâne deschisă.
| Unealtă | Sistem | Ce face |
|---|---|---|
| needrestart | Debian, Ubuntu | recunoaște serviciile cu fișiere depășite; sub Ubuntu, de la 24.04, le repornește implicit automat |
dnf needs-restarting -s |
familia RHEL | listează serviciile care ar trebui repornite |
Automatic-Reboot |
unattended-upgrades | repornește serverul dacă o actualizare o cere; implicit oprit |
reboot |
dnf-automatic | never, when-changed sau when-needed |
Potrivit documentației Ubuntu, serviciile excluse de needrestart continuă să ruleze cu fișiere vechi până la repornirea manuală. Verificați de aceea după fiecare actualizare PHP momentul de pornire al proceselor, așa cum este descris la Repornirea PHP-FPM și a tuturor workerilor.
La backporturi, numărul de versiune PHP afișat rămâne adesea același. Patchul îl dovediți prin changelog-ul pachetului cu numerele CVE, de exemplu cu apt-get changelog sau rpm -q --changelog. Cum procedați în detaliu arată Debian și Ubuntu: este pachetul meu PHP patchuit?.
Ce nu acoperă automatizarea
Actualizările automate sunt un element, nu o gestiune completă a patchurilor. Unele zone au nevoie de fluxuri proprii:
- Containere: PHP din imaginile Docker nu este actualizat prin actualizările gazdei. Reconstruiți imaginile, recreați containerele.
- Panouri de hosting: Plesk, cPanel și panouri similare administrează uneori PHP prin pachete și mecanisme proprii.
- Versiuni principale: Trecerea, de exemplu, de la PHP 8.2, care atinge sfârșitul suportului la 31.12.2026, la o versiune mai nouă nu se face automat.
- Aplicații: CMS-urile, pluginurile și dependențele Composer au căi proprii de actualizare.
- Control: Cineva trebuie să citească jurnalele și mesajele de eroare ale automatizării. O rulare care eșuează în tăcere este mai rea decât niciuna, pentru că simulează siguranță.
Cum se îmbină aceste părți într-un proces descrie Gestiunea patchurilor ca proces, nu ca intervenție de urgență.
Concluzie: automatizare da, încredere oarbă nu
Actualizările automate de securitate aparțin pe orice server Linux accesibil din internet. PHP2Shell a arătat cât de scurt poate deveni timpul: potrivit rapoartelor din presă, o primă tentativă de atac a fost observată deja la 17 octombrie, cu patru zile înaintea patchurilor. Cine aștepta după aceea o fereastră de întreținere manuală pierdea timp prețios.
Automatizarea vă preia însă doar aplicarea. Repornirea serviciilor, dovedirea nivelului de patchuri, containerele, panourile și trecerea la timp la versiuni suportate rămân sarcini pentru care cineva trebuie să fie responsabil. Stabiliți această responsabilitate în scris și verificați prin sondaj dacă jurnalele automatizării sunt într-adevăr citite. Abia combinația dintre automatizare și control face actualizările fiabile.
Cum ajută PHP SOS concret?
- Configurare: Configurăm unattended-upgrades sau dnf-automatic potrivit serverelor dumneavoastră, inclusiv sursele terțe permise.
- Asigurarea repornirilor: Configurăm needrestart sau verificări corespunzătoare și controlăm după actualizările PHP momentele de pornire ale proceselor.
- Închiderea lacunelor: Preluăm containerele, panourile și schimbările de versiune principală într-un flux fix de întreținere.
- Control: În contractul de mentenanță de securitate verificăm jurnalele automatizării și raportăm anomaliile.
Întrebări frecvente
Nu sunt actualizările automate prea riscante pe serverele de producție?
Limitat la actualizările de securitate ale distribuției, riscul este de regulă mai mic decât cel al unei vulnerabilități deschise. Aceste actualizări nu sunt menite să aducă funcții noi, ci să remedieze erori. Pentru sistemele critice fac parte din ele copiile de siguranță, supravegherea și un sistem de test.
Repornește unattended-upgrades PHP-FPM după o actualizare?
Nu neapărat singur. Sub Ubuntu, de la versiunea 24.04, unealta needrestart repornește implicit automat serviciile afectate, dar serviciile excluse continuă să ruleze cu fișiere vechi. Verificați după fiecare actualizare PHP momentul de pornire al tuturor proceselor PHP.
Sunt pachetele din sury.org sau din alte surse terțe actualizate automat?
Doar dacă permiteți explicit sursa. Potrivit documentației Ubuntu, nu este suficient să adăugați un depozit; el trebuie să figureze suplimentar în lista originilor permise ale unattended-upgrades.
Ridică automatizarea PHP 8.2 la 8.3?
Nu. Actualizările automate de securitate rămân în cadrul versiunilor de pachet instalate. O schimbare a versiunii principale PHP, de exemplu înaintea sfârșitului suportului pentru PHP 8.2 la 31.12.2026, rămâne un proiect planificat, cu teste.
Ce se întâmplă cu containerele Docker?
Actualizările de pe gazdă nu actualizează versiunea PHP din containere. Imaginile de container trebuie reconstruite sau descărcate din nou, iar containerele recreate.