Actualizari automate de securitate pe Debian si Ubuntu

Majoritatea serverelor compromise nu cad in mainile vreunui hacker genial. Sunt gasite de un bot care scaneaza tot internetul dupa o vulnerabilitate reparata de cateva saptamani, pe masini unde nimeni n-a rulat apt upgrade. Fix-ul exista, era gratuit si era la o comanda distanta. Doar ca serverul nu l-a primit niciodata.

Vestea buna e ca Debian si Ubuntu vin cu un instrument care inchide singur aceasta bresa: unattended-upgrades. In ghidul de fata il configuram pe un VPS proaspat, astfel incat sa instaleze zilnic patch-urile de securitate, sa-ti spuna ce a facut (intr-un fisier de log si, daca vrei, pe email) si sa reporneasca serverul la o ora linistita atunci cand un update de kernel o cere. Totul e scris pentru Debian 13 (trixie) si Ubuntu 24.04 LTS (noble), iar acolo unde cele doua se comporta diferit, iti spunem explicit.

Instrumentul e dezvoltat public pe github.com/mvo5/unattended-upgrades si e impachetat de ambele distributii, deci nu descarci nimic din surse terte: totul vine din repository-urile oficiale pe care le folosesti deja.

Ce face, de fapt, unattended-upgrades

Intai cateva notiuni de baza. Software-ul pe Debian si Ubuntu vine sub forma de pachete: arhive care contin un program plus instructiunile de instalare. Pachetele sunt publicate in repository-uri, servere (mirror-e) care tin pachetele si un index cu versiunile disponibile. Unealta care vorbeste cu repository-urile este apt.

Cand cineva repara o gaura de securitate in, sa zicem, OpenSSL sau OpenSSH, mentenantii publica o versiune noua a pachetului intr-un repository de securitate dedicat. Pe Debian 13 se numeste trixie-security, pe Ubuntu 24.04 este pocket-ul noble-security. Serverul tau primeste fix-ul doar cand apt il descarca si il instaleaza. Pana atunci, gaura ramane deschisa, desi patch-ul sta pe un mirror la cateva milisecunde distanta.

unattended-upgrades este un mic program Python care face aceasta instalare in locul tau, dar numai din repository-urile pe care le permiti si numai pentru pachetele care nu au nevoie de un om sa raspunda la o intrebare (de exemplu “pastrezi fisierul de configurare modificat sau il iei pe cel nou?”). Nu e un daemon care ruleaza permanent. E pornit de doua timere systemd. Un timer este echivalentul integrat in systemd al unui cron job: o regula care spune “porneste serviciul asta la ora asta”.

• apt-daily.timer ruleaza de doua ori pe zi, actualizeaza listele de pachete si descarca ce e disponibil.
• apt-daily-upgrade.timer ruleaza o data pe zi si porneste unattended-upgrade, care instaleaza actualizarile permise.

Ce nu face

Merita sa fim clari in privinta limitelor, ca sa nu ai surprize mai tarziu:

• Nu face niciodata upgrade de versiune. Debian 13 ramane Debian 13, Ubuntu 24.04 ramane 24.04. Trecerea la urmatoarea versiune majora e mereu o operatiune manuala, planificata.
• Ignora repository-urile pe care nu le-ai permis. Pachetele din repository-uri terte (Docker, un repository de PHP, un producator de baze de date) nu sunt atinse decat daca le adaugi explicit.
• Nu schimba kernelul care ruleaza. Kernelul este nucleul sistemului de operare, partea incarcata la boot care vorbeste cu hardware-ul. Un pachet nou de kernel se instaleaza pe disc, dar cel vechi ramane activ pana la urmatorul reboot. De aceea configuram reboot automat la pasul 6.
• Nu e o strategie de securitate de unul singur. Firewall-ul, cheile SSH in loc de parole si backup-urile raman importante. unattended-upgrades inchide categoria de gauri “cunoscute si deja reparate”, care se intampla sa fie si cea mai exploatata.

De ce merita actualizarile automate de securitate

Calculul e simplu. Daca faci patch manual o data pe luna, un fix publicat intr-un moment oarecare asteapta in medie cam 15 zile pana ajunge pe serverul tau. Cu patch saptamanal, media scade la circa 3,5 zile. Cu unattended-upgrades rulat zilnic, asteptarea coboara mult sub o zi, pentru ca singura intarziere ramasa e timpul pana la urmatoarea rulare a timerului.

Intre timp, scanerele automate incep de obicei sa caute o vulnerabilitate proaspat publicata in cateva zile, uneori in cateva ore. Cu cat fereastra ta e mai lunga, cu atat creste sansa ca un bot sa ajunga primul.

“Si daca un update strica ceva?” e obiectia clasica si e o intrebare corecta. Distributiile stabile trateaza securitatea altfel decat cele rolling: echipele de securitate Debian si Ubuntu porteaza fix-ul in aceeasi versiune pe care o rulezi deja, in loc sa livreze o versiune majora noua, cu comportament nou. Pe serverele pe care le administram, problemele cauzate de un update de securitate sunt rare, mult mai rare decat incidentele cauzate de un update lipsa. Pentru cele cateva pachete unde vrei control total, le poti tine pe loc, si iti aratam cum.

Debian 13 vs Ubuntu 24.04: diferentele care conteaza

Unealta e aceeasi pe ambele, dar setarile implicite din jurul ei nu. Tine tabelul asta in minte cat urmezi pasii:

Retine ca /var/run este un link simbolic catre /run pe ambele sisteme, deci /var/run/reboot-required si /run/reboot-required sunt acelasi fisier.

De ce ai nevoie

• Un VPS cu Debian 13 sau Ubuntu 24.04, KVM sau LXC (diferentele pentru LXC le explicam mai jos).
• Acces SSH cu un utilizator care are drepturi sudo.
• Cam 15 minute.
• Optional, pentru rapoarte pe email: un cont SMTP (de la furnizorul tau de email sau de la un serviciu de email tranzactional), cu utilizator si parola.
• Recomandat: un backup sau snapshot recent al serverului, ca inaintea oricarei schimbari de configurare.

Iata planul. Fiecare pas numerotat mai jos corespunde unui titlu din restul ghidului.

Pasul 1: Verifica ce exista deja

Inainte sa schimbam ceva, vedem pe ce sistem suntem si daca unattended-upgrades e deja instalat:

grep PRETTY_NAME /etc/os-release
dpkg -l unattended-upgrades 2>/dev/null | grep '^ii' || echo "unattended-upgrades nu este instalat"
ls /etc/apt/apt.conf.d/ | grep -E 'auto-upgrades|unattended' || echo "inca nu exista configuratie"
systemd-detect-virt

Ce iti spune fiecare linie:

• Prima afiseaza ceva de genul PRETTY_NAME="Debian GNU/Linux 13 (trixie)" sau PRETTY_NAME="Ubuntu 24.04.3 LTS".
• A doua afiseaza o linie care incepe cu ii unattended-upgrades daca pachetul e instalat, altfel mesajul nostru “nu este instalat”.
• A treia listeaza 20auto-upgrades si 50unattended-upgrades daca exista. Pe Ubuntu le vei vedea de obicei pe amandoua.
• Ultima afiseaza tipul de virtualizare: kvm pe un VPS KVM, lxc intr-un container LXC.

Daca esti pe Ubuntu si totul e deja acolo, nu sari peste restul: configuratia implicita instaleaza update-uri, dar nu trimite rapoarte si nu reporneste niciodata, deci un fix de kernel poate sta pe disc luni intregi fara sa fie activ.

Pasul 2: Instaleaza unattended-upgrades

Actualizam listele de pachete si instalam pachetul (pe Ubuntu, asta doar confirma ca e instalat):

sudo apt update
sudo apt install -y unattended-upgrades

apt update descarca indexurile de pachete actualizate din repository-uri; apt install instaleaza unealta si dependentele ei. Comanda ar trebui sa se termine fara erori. Pe Debian, pachetul pune si un mic hook in /etc/kernel/postinst.d/ care creeaza fisierul de reboot dupa instalarea unui kernel, lucru pe care ne bazam la pasul 6.

Pasul 3: Activeaza rularea zilnica

Nu ajunge sa instalezi pachetul: apt trebuie instruit sa-l ruleze periodic. Cea mai prietenoasa metoda e dialogul de configurare integrat:

sudo dpkg-reconfigure -plow unattended-upgrades

La intrebarea “Automatically download and install stable updates?” alegi Yes. Asta scrie fisierul /etc/apt/apt.conf.d/20auto-upgrades. Daca preferi sa-l scrii de mana (util in scripturi), varianta de mai jos face acelasi lucru si in plus curata saptamanal cache-ul de pachete descarcate:

sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
EOF

Valorile "1" inseamna “la fiecare 1 zi”. Acum confirmam ca apt vede setarile si ca ambele timere sunt active:

apt-config dump APT::Periodic
systemctl list-timers 'apt-daily*'

Prima comanda trebuie sa contina APT::Periodic::Update-Package-Lists "1"; si APT::Periodic::Unattended-Upgrade "1";. A doua arata doua randuri, apt-daily.timer si apt-daily-upgrade.timer, fiecare cu o ora NEXT in viitor. Daca lipseste un timer, il activezi cu sudo systemctl enable --now apt-daily-upgrade.timer (sau apt-daily.timer).

Pasul 4: Alege ce actualizari se instaleaza

Configuratia principala sta in /etc/apt/apt.conf.d/50unattended-upgrades. Deschide-l ca sa-l citesti, dar nu-l vom edita: cand pachetul primeste o versiune noua a acestui fisier, modificarile tale ar declansa intrebarea “ce versiune pastrezi?”, iar intrebarea asta blocheaza chiar actualizarea automata a uneltei. In schimb, punem setarile noastre intr-un fisier separat, citit dupa el. apt citeste fisierele din apt.conf.d in ordine alfabetica, deci un fisier numit 52... suprascrie valorile din 50....

Intai, uita-te ce surse (repository-uri) sunt permise. Pe Debian 13 vei gasi:

Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename},label=Debian";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

Pe Ubuntu 24.04 aceeasi idee foloseste alta cheie:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESMApps:${distro_codename}-apps-security";
        "${distro_id}ESM:${distro_codename}-infra-security";
};

${distro_codename} e inlocuit automat cu trixie sau noble. Pe Debian, prima linie aduce si point release-urile stabile, pachetele conservatoare de bugfix-uri pe care Debian le publica la cateva luni. Recomandam s-o lasi activa. Pe Ubuntu, liniile ESM conteaza doar daca masina e atasata la Ubuntu Pro; altfel nu se potrivesc cu nimic si nu deranjeaza. Liniile -updates sunt comentate pe ambele, ceea ce e o alegere buna pentru servere: doar securitate, nimic experimental. Nu activa niciodata -proposed sau -backports aici.

Ca sa vezi exact numele surselor pe care le cunoaste serverul, ruleaza:

apt-cache policy | grep -E 'release' | sort -u

Vei vedea linii ca release v=13,o=Debian,a=stable-security,n=trixie-security,l=Debian-Security,c=main. Valorile o= (origin), n= (codename) si l= (label) sunt cele cu care se potrivesc regulile.

Acum cream fisierul nostru local de suprascriere, cu cateva optiuni de curatenie:

sudo tee /etc/apt/apt.conf.d/52unattended-upgrades-local > /dev/null <<'EOF'
// Setari locale pentru unattended-upgrades
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::SyslogEnable "true";
EOF

Prima optiune sterge kernelurile vechi dupa instalarea unuia nou, ca /boot si discul sa nu se umple in timp. A doua sterge dependentele ramase nefolosite in urma unui upgrade automat. A treia trimite mesajele uneltei si in jurnalul sistemului.

Daca ai un pachet pe care nu vrei sa-l actualizezi niciodata automat (de exemplu o baza de date pe care o actualizezi doar in ferestre de mentenanta), cea mai simpla metoda e un hold in apt, pe care unattended-upgrades il respecta:

sudo apt-mark hold mariadb-server
apt-mark showhold

Il anulezi mai tarziu cu sudo apt-mark unhold mariadb-server. Foloseste hold-urile cu masura: un pachet tinut pe loc nu mai primeste nici fixuri de securitate.

Pasul 5: Primeste rapoarte pe email

Logurile sunt bune, dar un email dupa fiecare schimbare e si mai bun: vezi ce s-a actualizat fara sa te loghezi. unattended-upgrades trimite mail prin comanda standard sendmail, deci avem nevoie de un mic program care o ofera. Folosim msmtp, un client usor care trimite mailul mai departe catre un server SMTP real, in loc sa rulezi un server de mail complet pe VPS:

sudo apt install -y msmtp-mta bsd-mailx ca-certificates

msmtp-mta ofera /usr/sbin/sendmail, iar bsd-mailx ofera comanda mail pentru teste. Daca instalarea te intreaba daca activezi suportul AppArmor pentru msmtp, raspunsul implicit e in regula. Acum scriem configuratia, inlocuind host-ul, adresele si parola cu datele contului tau SMTP:

sudo tee /etc/msmtprc > /dev/null <<'EOF'
defaults
auth            on
tls             on
tls_trust_file  /etc/ssl/certs/ca-certificates.crt
syslog          LOG_MAIL

account         default
host            smtp.example.com
port            587
from            server1@example.com
set_from_header on
user            server1@example.com
password        SCHIMBA_MA
EOF
sudo chown root:root /etc/msmtprc
sudo chmod 600 /etc/msmtprc

Portul 587 e portul standard de “submission” pentru trimitere autentificata si merge mult mai bine decat livrarea directa pe portul 25. set_from_header on face ca fiecare mesaj sa foloseasca adresa ta reala de expeditor, lucru cerut de majoritatea furnizorilor SMTP. Fisierul contine o parola, deci doar root are voie sa-l citeasca. Trimite un test:

echo "Test de pe $(hostname)" | sudo mail -s "test msmtp" tu@example.com

Daca ajunge, ii spunem lui unattended-upgrades unde sa trimita rapoartele:

sudo tee -a /etc/apt/apt.conf.d/52unattended-upgrades-local > /dev/null <<'EOF'
Unattended-Upgrade::Mail "tu@example.com";
Unattended-Upgrade::Sender "server1@example.com";
Unattended-Upgrade::MailReport "on-change";
EOF

MailReport accepta always, only-on-error sau on-change. Noua ne place on-change: primesti email doar cand s-a instalat ceva sau a esuat ceva, deci mesajele raman relevante si nu devin zgomot zilnic.

Pasul 6: Reboot automat la o ora sigura

Majoritatea actualizarilor au efect imediat: cand o biblioteca precum OpenSSL e actualizata, serviciile afectate sunt repornite si incarca noul cod. Kernelul e diferit, se schimba doar la boot. Asa ca il lasam pe unattended-upgrades sa reporneasca serverul, dar numai cand e nevoie si numai la o ora cand nu-l foloseste nimeni.

Intai, asigura-te ca ceasul serverului foloseste fusul tau orar, altfel “04:00” inseamna 04:00 UTC:

timedatectl
sudo timedatectl set-timezone Europe/Bucharest

Apoi adaugi setarile de reboot:

sudo tee -a /etc/apt/apt.conf.d/52unattended-upgrades-local > /dev/null <<'EOF'
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
EOF
apt-config dump Unattended-Upgrade | grep -E 'Mail|Reboot|Remove'

Ultima comanda afiseaza valorile efective, ca sa confirmi ca suprascrierile au fost preluate. Dupa fiecare rulare, unattended-upgrades verifica existenta /run/reboot-required. Daca fisierul exista, programeaza un reboot la 04:00; daca nu, nu se intampla nimic. Automatic-Reboot-WithUsers "true" inseamna ca reporneste chiar daca cineva a uitat o sesiune SSH deschisa, exact ce vrei pe un server.

Implicit, apt-daily-upgrade.timer ruleaza in jurul orei 06:00, deci un kernel instalat dimineata ar astepta aproape o zi intreaga pana la reboot-ul de la 04:00. Mutam upgrade-ul la 03:00, iar actualizarea listelor ceva mai devreme, ca tot ciclul sa se petreaca intr-o singura noapte linistita:

sudo mkdir -p /etc/systemd/system/apt-daily-upgrade.timer.d /etc/systemd/system/apt-daily.timer.d
sudo tee /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf > /dev/null <<'EOF'
[Timer]
OnCalendar=
OnCalendar=*-*-* 03:00
RandomizedDelaySec=20m
EOF
sudo tee /etc/systemd/system/apt-daily.timer.d/override.conf > /dev/null <<'EOF'
[Timer]
OnCalendar=
OnCalendar=*-*-* 01:00
OnCalendar=*-*-* 13:00
RandomizedDelaySec=30m
EOF
sudo systemctl daemon-reload
sudo systemctl restart apt-daily.timer apt-daily-upgrade.timer
systemctl list-timers 'apt-daily*'

Linia goala OnCalendar= sterge programul implicit inainte sa-l setam pe al nostru. RandomizedDelaySec adauga o mica intarziere aleatoare, ca sa nu loveasca multe servere mirror-ele in aceeasi secunda. Lista de timere ar trebui sa arate acum urmatoarele rulari in jurul orelor 01:00/13:00 si 03:00.

Atentie la diferenta Debian vs Ubuntu: pe Ubuntu, /run/reboot-required e creat de update-notifier-common dupa update-uri de kernel si ale unor biblioteci de baza, iar /run/reboot-required.pkgs iti spune ce pachete l-au cerut. Pe Debian, fisierul vine din hook-ul de kernel instalat odata cu unattended-upgrades, deci apare in principal dupa update-uri de kernel, iar fisierul .pkgs poate lipsi. Poti verifica manual oricand:

ls -l /run/reboot-required* 2>/dev/null || echo "nu e nevoie de reboot"
uname -r

uname -r arata kernelul care ruleaza chiar acum. Pentru serviciile care inca folosesc in memorie versiuni vechi ale unor biblioteci, te ajuta needrestart. Pe Ubuntu e preinstalat; pe Debian il instalezi cu sudo apt install -y needrestart, apoi listezi ce ar avea nevoie de restart, fara sa reporneasca nimic:

sudo needrestart -r l

Intr-un container LXC neprivilegiat, kernelul apartine host-ului, nu containerului tau, deci nu exista pachet de kernel de actualizat si fisierul de reboot apare rar. Daca totusi apare, “reboot” inseamna doar repornirea containerului, care dureaza cateva secunde. Kernelul host-ului e actualizat de furnizor. Pe un VPS KVM, serverul are propriul kernel si pasii de mai sus se aplica integral.

Daca preferi sa nu reporneasca automat, lasa Automatic-Reboot pe "false". Emailul de raport primeste atunci eticheta [reboot required] in subiect, iar tu repornesti manual in fereastra ta de mentenanta.

Pasul 7: Testeaza cu un dry-run si citeste logurile

Nu astepta pana maine ca sa afli daca merge. Un dry-run parcurge tot procesul de decizie fara sa instaleze nimic:

sudo unattended-upgrade --dry-run --debug

Rezultatul e lung. Cauta linii ca acestea:

Starting unattended upgrades script
Allowed origins are: origin=Debian,codename=trixie,label=Debian, origin=Debian,codename=trixie,label=Debian-Security, ...
Packages that will be upgraded: libssl3t64 openssl

Daca nu e nimic de instalat, vei vedea No packages found that can be upgraded unattended and no pending auto-removals, ceea ce tot succes inseamna. Daca vrei sa aplici imediat update-urile in asteptare, fara sa astepti noaptea, ruleaza-l real cu sudo unattended-upgrade -v.

De acum inainte, acestea sunt locurile in care te uiti:

sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
grep -A4 'Start-Date' /var/log/apt/history.log | tail -n 20
journalctl -u apt-daily-upgrade.service --since "3 days ago"

Primul fisier e rezumatul fiecarei rulari (ce era permis, ce s-a instalat, daca s-a programat un reboot). Al doilea contine iesirea detaliata a instalarii pachetelor. history.log inregistreaza orice operatiune apt, manuala sau automata. Jurnalul arata cand a pornit efectiv timerul. Cand e programat un reboot, vei vedea in primul log o linie asemanatoare cu Found /var/run/reboot-required, rebooting, iar cat /run/systemd/shutdown/scheduled iti arata ora reboot-ului programat.

Probleme frecvente si greseli comune

“Could not get lock /var/lib/dpkg/lock-frontend”. Ai rulat apt in timp ce unattended-upgrades lucra. Asteapta cateva minute si incearca din nou. Nu sterge niciodata fisierele de lock ca sa “rezolvi” problema: intreruperea lui dpkg in mijlocul unei instalari e exact felul in care ajungi cu pachete stricate.

Nu se actualizeaza niciodata nimic. Ruleaza apt-config dump APT::Periodic si verifica sa existe Unattended-Upgrade "1". Pe Ubuntu exista si /etc/apt/apt.conf.d/10periodic; castiga fisierul citit ultimul, iar dump-ul arata rezultatul final. Verifica si systemctl is-enabled apt-daily-upgrade.timer si ruleaza dry-run-ul de la pasul 7 ca sa vezi ce surse sunt permise.

Un pachet e “kept back” cu un mesaj despre conffile. Logul spune ceva de genul “Package X has conffile prompt and needs to be upgraded manually”. Ai modificat un fisier de configurare pe care si versiunea noua il schimba, iar unattended-upgrades refuza sa ghiceasca. Ruleaza tu sudo apt upgrade si decide.

Ubuntu amana unele update-uri. Ubuntu distribuie unele update-uri in etape, catre un procent de masini pe rand. Un pachet “deferred due to phasing” va veni in cateva zile; e normal.

Nu vin emailuri. Testeaza cu comanda mail de la pasul 5, apoi citeste mesajele msmtp cu journalctl -t msmtp -n 20. Pe Debian 13 nu exista /var/log/syslog implicit, deci jurnalul e locul unde te uiti; pe Ubuntu poti folosi si grep msmtp /var/log/syslog. Parola gresita, portul gresit si o adresa de expeditor neacceptata de furnizor sunt cauzele obisnuite.

Serverul nu reporneste niciodata. Verifica sa apara Automatic-Reboot "true" in apt-config dump, ca fisierul de reboot sa existe cu adevarat si ca fusul orar sa fie cel asteptat. Nu uita ca pe Debian doar update-urile de kernel creeaza fisierul.

Pachetele de la Docker sau alti producatori nu se actualizeaza. Asa e gandit. Daca ai incredere intr-un repository tert, afla-i origin-ul si label-ul cu apt-cache policy si adauga o linie potrivita in fisierul local, de exemplu Unattended-Upgrade::Origins-Pattern { "origin=Docker,label=Docker CE"; };. Gandeste-te de doua ori: un salt de versiune majora de la un producator poate schimba comportamentul peste noapte.

Note de securitate

• Protejeaza parola SMTP. Tine /etc/msmtprc detinut de root, cu permisiuni 600, si foloseste un cont SMTP dedicat sau o parola de aplicatie, nu parola casutei tale principale.
• Ramai pe sursele de securitate. Nu adauga -proposed, -backports sau PPA-uri oarecare in lista permisa. Scopul sunt fixuri minime si previzibile.
• Pastreaza backup-urile oricum. Actualizarile automate reduc riscul, nu il elimina. Un backup zilnic, stocat in afara serverului, e plasa ta de siguranta pentru orice schimbare, automata sau manuala.
• Monitorizeaza reboot-ul. Daca activezi reboot automat, pune un check extern de uptime pe site sau pe portul SSH, ca sa afli daca serverul nu revine dupa 04:00.
• Nu dezactiva timerele “temporar”. Un timer dezactivat se uita usor, iar un server uitat e exact ce cauta boturile. Daca ai nevoie de o pauza, foloseste apt-mark hold pe pachete anume.
• Patch-urile sunt doar un strat. Combina-le cu un firewall care deschide doar porturile folosite, autentificare SSH cu chei si login root dezactivat prin SSH.

Deci, il lasi pe server sa se actualizeze singur?

Pentru aproape orice VPS: da. Cu vreo 15 minute de configurare, unattended-upgrades instaleaza fixurile de securitate la cateva ore dupa publicare, iti trimite email cand se schimba ceva, curata kernelurile vechi si reporneste la 04:00 doar cand un kernel nou asteapta. Cele cateva cazuri in care vrei control manual (o baza de date, un stack de aplicatie fixat pe o versiune) se rezolva cu hold-uri, nu oprind tot mecanismul.

Daca vrei sa incerci pe o masina curata, un VPS de la noi ruleaza Debian 13 sau Ubuntu 24.04 si e gata in cateva minute. Iar daca preferi ca altcineva sa se ocupe cap-coada de patch-uri, reboot-uri si monitorizare, echipa noastra de administrare servere le poate configura si urmari pentru tine.

Intrebari frecvente

Face unattended-upgrades upgrade de la Debian 13 la Debian 14 sau de la Ubuntu 24.04 la urmatorul LTS?

Nu. Instaleaza doar actualizari in cadrul versiunii curente. Trecerea la o versiune majora noua e un proces separat, manual, pe care e bine sa-l planifici si sa-l testezi.

Imi cade site-ul in timpul actualizarilor?

De obicei nu, in niciun fel vizibil. Un serviciu ca Nginx sau PHP-FPM se poate reporni o secunda-doua cand pachetul lui e actualizat. Singura intrerupere reala e reboot-ul, de aceea il programam la 04:00 si doar cand un update de kernel il cere.

E sigur sa activez reboot automat pe un server de productie?

Pentru un singur VPS cu boot rapid, da, cu conditia ca serviciile tale sa porneasca automat la boot (containere Docker cu restart policy, servicii systemd activate) si sa ai un check de uptime. Pentru setup-uri unde reboot-ul trebuie coordonat intre mai multe servere, lasa Automatic-Reboot oprit si reporneste intr-o fereastra planificata.

Functioneaza intr-un container LXC?

Da, pentru toate pachetele obisnuite. Kernelul e partajat cu host-ul, deci nu exista update-uri de kernel in container, iar reboot-urile sunt rare si rapide. Kernelul host-ului e intretinut de furnizor.

Cum il opresc daca am nevoie?

Pune ambele valori din /etc/apt/apt.conf.d/20auto-upgrades pe "0", sau ruleaza sudo dpkg-reconfigure -plow unattended-upgrades si raspunde No. Nu uita sa-l repornesti apoi.