# Automātiski drošības atjauninājumi Linux serveros

> unattended-upgrades un dnf-automatic ieviešana: drošības atjauninājumus ieviest automātiski, pārstartēt pakalpojumus un mērķtiecīgi atļaut trešo pušu avotus.

Avots: https://phpsos.de/lv/blog/automatische-sicherheitsupdates/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Īsi sakot:** Ar `unattended-upgrades` zem Debian un Ubuntu, kā arī `dnf-automatic` RHEL saimē Linux serveri drošības atjauninājumus ievieš paši. Lai atjauninājums darbotos, skartajiem pakalpojumiem, piemēram, PHP-FPM, pēc tam jāpārstartējas; pārbaudiet to ar needrestart vai procesu startēšanas laikiem. Trešo pušu avoti, piemēram, sury.org, jāatļauj nepārprotami, konteineru un galveno versiju maiņu automātika neaptver.

## No ielāpa līdz serverim: automātika ietaupa laiku

Kad php.net 2026. gada 21. oktobrī plkst. 16:00 pēc Vācijas laika publicēja ielāpus pret PHP2Shell, administratoriem sākās sacensība. Saskaņā ar ziņojumiem distributīvi savus backport dažkārt piegādāja jau tajā pašā dienā. Serveri ar automātiskiem drošības atjauninājumiem jaunās pakotnes varēja instalēt nākamajā plānotajā palaišanā, kādam neiejaucoties.

Tā ir labā ziņa. Mazāk labā: instalēts nenozīmē darbojas. PHP-FPM pakalpojums, kas darbojas jau nedēļām, ar veco kodu atmiņā turpina strādāt, līdz tiek pārstartēts. Un pakotnes no trešo pušu avotiem, konteineri vai hostinga paneļi ar savu PHP pārvaldību automātikai bieži paliek neskarti.

Šis raksts rāda, kā ieviest automātiskus drošības atjauninājumus un tā papildināt, lai tie nopietnā situācijā patiešām aizsargā.

## unattended-upgrades zem Debian un Ubuntu

Zem Ubuntu pakotne `unattended-upgrades` pēc noklusējuma ir instalēta un ievieš drošības atjauninājumus. Zem Debian to pēc vajadzības instalējat papildus. Tā tiek vadīta ar diviem failiem zem `/etc/apt/apt.conf.d/`.

```bash
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
```

Fails `20auto-upgrades` nosaka, vai un cik bieži tiek atjaunināti pakotņu saraksti un ieviesti atjauninājumi. Vērtība ir dienu skaits, `"1"` nozīmē katru dienu:

```text
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
```

Failā `50unattended-upgrades` ir norādīts, no kādiem avotiem atjauninājumi drīkst nākt, vai pēc tam tiek pārstartēts un kas saņem ziņojumu. Pēc noklusējuma atļauti ir tikai distributīva oficiālie drošības avoti. Saskaņā ar Ubuntu dokumentāciju nepietiek ar vēl viena repozitorija iekļaušanu: tam papildus jābūt šajā sarakstā, citādi automātika to ignorē. Tas attiecas, piemēram, uz trešās puses repozitoriju sury.org, kas saskaņā ar ziņojumiem piegādājis PHP būvējumus visiem zariem no 5.6 līdz 8.5. Fona informācija atrodama rakstā [sury.org repozitorijs](https://phpsos.de/lv/blog/sury-repository-php/).

Vai viss kārtībā, parāda mēģinājuma palaišana, kas neko nemaina:

```bash
sudo unattended-upgrade -v --dry-run
# Īsto palaišanu protokoli
ls -l /var/log/unattended-upgrades/
```

## dnf-automatic RHEL, AlmaLinux un Rocky Linux

RHEL saimē `dnf-automatic` pilda to pašu uzdevumu. Konfigurācija atrodas `/etc/dnf/automatic.conf`. Saskaņā ar dokumentāciju `upgrade_type = security` pārbauda tikai atjauninājumus ar drošības norādi, un `apply_updates` pēc noklusējuma ir izslēgts.

```ini
# /etc/dnf/automatic.conf (izvilkums)
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never
```

```bash
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers 'dnf-automatic*'
```

Līdzās `dnf-automatic.timer`, kas seko konfigurācijas failam, ir taimeri, kas tikai ziņo, tikai lejupielādē vai vienmēr instalē. Sākumam taimeris ar konfigurācijas failu ir visizsekojamākais.

## Nenovērtētā daļa: pakalpojumu pārstartēšana

Pakotņu pārvaldnieks aizstāj failus diskā. Darbojošies procesi atmiņā saglabā veco kodu. PHP gadījumā tas nozīmē: kamēr PHP-FPM vai Apache ar mod_php nav pārstartēti, ievainojamība paliek atvērta.

| Rīks | Sistēma | Ko tas dara |
|---|---|---|
| needrestart | Debian, Ubuntu | atpazīst pakalpojumus ar novecojušiem failiem; zem Ubuntu no 24.04 pēc noklusējuma tos pārstartē automātiski |
| `dnf needs-restarting -s` | RHEL saime | uzskaita pakalpojumus, kas jāpārstartē |
| `Automatic-Reboot` | unattended-upgrades | pārstartē serveri, ja atjauninājums to prasa; pēc noklusējuma izslēgts |
| `reboot` | dnf-automatic | `never`, `when-changed` vai `when-needed` |

Saskaņā ar Ubuntu dokumentāciju pakalpojumi, kas needrestart ir izņemti, līdz manuālai pārstartēšanai turpina darboties ar vecajiem failiem. Pēc katra PHP atjauninājuma tāpēc pārbaudiet procesu startēšanas laiku, kā aprakstīts sadaļā [PHP-FPM un visu worker procesu pārstartēšana](https://phpsos.de/lv/php2shell/php-fpm-neustart/).

> **Svarīgi:**
> Backport gadījumā parādītais PHP versijas numurs bieži paliek tas pats. Ielāpu pierādiet ar pakotnes changelog ar CVE numuriem, piemēram, ar `apt-get changelog` vai `rpm -q --changelog`. Kā tas darbojas detalizēti, rāda [Debian un Ubuntu: vai mana PHP pakotne ir ielāpota?](https://phpsos.de/lv/blog/debian-ubuntu-paket-gepatcht/).

## Ko automātika neaptver

Automātiski atjauninājumi ir viens elements, nevis pilnīga ielāpu pārvaldība. Dažām jomām vajadzīgi savi procesi:

1. **Konteineri:** PHP Docker attēlos resursdatora atjauninājumi neatjaunina. Attēlus pārbūvēt, konteinerus izveidot no jauna.
2. **Hostinga paneļi:** Plesk, cPanel un līdzīgi paneļi PHP daļēji pārvalda ar savām pakotnēm un mehānismiem.
3. **Galvenās versijas:** pāreja, piemēram, no PHP 8.2, kas 2026. gada 31. decembrī sasniedz atbalsta beigas, uz jaunāku versiju nenotiek automātiski.
4. **Lietojumprogrammas:** CMS, spraudņiem un Composer atkarībām ir savi atjaunināšanas ceļi.
5. **Kontrole:** kādam jāizlasa automātikas protokoli un kļūdu ziņojumi. Klusi izgāzusies palaišana ir sliktāka par nevienu, jo tā simulē drošību.

Kā šīs daļas saaug procesā, apraksta [Ielāpu pārvaldība kā process, nevis ugunsdzēsība](https://phpsos.de/lv/blog/patch-management-prozess/).

## Secinājums: automātika jā, akla uzticēšanās nē

Automātiski drošības atjauninājumi pieder katram Linux serverim, kas sasniedzams no interneta. PHP2Shell ir parādījusi, cik šaurs var kļūt laiks: saskaņā ar plašsaziņas līdzekļu ziņojumiem pirmais uzbrukuma mēģinājums tika novērots jau 17. oktobrī, četras dienas pirms ielāpiem. Kas pēc tam vēl gaida manuālu uzturēšanas logu, tas zaudē vērtīgu laiku.

Automātika jums noņem tikai ieviešanu. Pakalpojumu pārstartēšana, ielāpu stāvokļa pierādījums, konteineri, paneļi un savlaicīga pāreja uz atbalstītām versijām paliek uzdevumi, par kuriem kādam jābūt atbildīgam. Noteiciet šo atbildību rakstiski un izlases veidā pārbaudiet, vai automātikas protokoli patiešām tiek lasīti. Tikai automātikas un kontroles kombinācija atjauninājumus dara uzticamus.

## Kā PHP SOS palīdz konkrēti?

- **Ieviest:** mēs konfigurējam unattended-upgrades vai dnf-automatic atbilstoši jūsu serveriem, ieskaitot atļautos trešo pušu avotus.
- **Nodrošināt pārstartēšanas:** mēs ieviešam needrestart vai atbilstošas pārbaudes un pēc PHP atjauninājumiem kontrolējam procesu startēšanas laikus.
- **Aizvērt robus:** konteinerus, paneļus un galveno versiju maiņu mēs iekļaujam fiksētā uzturēšanas procesā.
- **Kontrolēt:** [drošības uzturēšanas līgumā](https://phpsos.de/lv/leistungen/security-wartungsvertrag/) mēs pārbaudām automātikas protokolus un ziņojam par uzkrītošo.


## Biežāk uzdotie jautājumi

**Vai automātiski atjauninājumi produkcijas serveros nav pārāk riskanti?**  
Ierobežoti uz distributīva drošības atjauninājumiem risks parasti ir mazāks nekā atvērtas ievainojamības risks. Šiem atjauninājumiem nav jānes jaunas funkcijas, bet jālabo kļūdas. Kritiskām sistēmām klāt pieder rezerves kopijas, uzraudzība un testa sistēma.

**Vai unattended-upgrades pēc atjauninājuma pārstartē PHP-FPM?**  
Ne obligāti pats. Zem Ubuntu no versijas 24.04 rīks needrestart skartos pakalpojumus pēc noklusējuma pārstartē automātiski, bet izņēmuma pakalpojumi turpina darboties ar vecajiem failiem. Pēc katra PHP atjauninājuma pārbaudiet visu PHP procesu startēšanas laiku.

**Vai pakotnes no sury.org vai citiem trešo pušu avotiem tiek atjauninātas automātiski?**  
Tikai tad, ja avotu nepārprotami atļaujat. Saskaņā ar Ubuntu dokumentāciju nepietiek ar repozitorija pievienošanu; tam papildus jābūt unattended-upgrades atļauto izcelsmju sarakstā.

**Vai automātika paaugstina arī PHP 8.2 uz 8.3?**  
Nē. Automātiski drošības atjauninājumi paliek uzstādīto pakotņu versiju robežās. PHP galvenās versijas maiņa, piemēram, pirms PHP 8.2 atbalsta beigām 2026. gada 31. decembrī, paliek plānots projekts ar testiem.

**Kā ar Docker konteineriem?**  
Atjauninājumi resursdatorā PHP versiju konteineros neatjaunina. Konteineru attēli jāpārbūvē vai jāpārvelk un konteineri jāizveido no jauna.

## Avoti

- [Ubuntu Server: automātiskie atjauninājumi](https://ubuntu.com/server/docs/how-to/software/automatic-updates/)
- [DNF Automatic](https://dnf.readthedocs.io/en/latest/automatic.html)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [Ubuntu Security Notices](https://ubuntu.com/security/notices)
