Your server hasn't been updated for months, and then one Friday an RCE in OpenSSL hits. If you update manually — you're too late. Automatic security patching via Unattended-Upgrades or dnf-automatic closes CVEs without human intervention. The configuration takes a few hours, after which you don't need to SSH in every week. We have been configuring these systems on Linux servers for over 5 years — more than 500 servers running Debian/Ubuntu and RHEL. During that time, we developed a standard: patch security updates within 24 hours of release, minimize downtime, full control via Ansible.
Why Automatic Patching Is Necessary
70% of successful attacks on Linux infrastructure exploit known vulnerabilities for which patches already exist. Manual update process: find CVE, log into each server, run apt upgrade or dnf update, restart services. For 50 servers, it takes a full admin day. Automation reduces that time to zero and eliminates human error: forgotten servers, missed packages, version inconsistency. We deploy systems that automatically check and install security updates as soon as they are released. We guarantee that after setup, your service uptime remains at 99.9%. In a recent project with a mixed fleet of 200 servers, we cut manual patching time from 8 hours per week to zero, and reduced critical CVE response from 12 hours to 1 hour.
How Unattended-Upgrades Works on Debian/Ubuntu
The package is pre-installed on most modern Ubuntu versions. The main config is /etc/apt/apt.conf.d/50unattended-upgrades:
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
// "${distro_id}:${distro_codename}-updates";
// optional
};
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Automatic-Reboot "false" — intentionally. Automatic reboot of production servers without a maintenance window is a bad idea. Kernel and glibc updates require a reboot, but it's better to schedule manually or via a separate tool (e.g., kured for Kubernetes nodes).
Activation via /etc/apt/apt.conf.d/20auto-upgrades:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
Dry-run test: unattended-upgrade --dry-run --debug.
How to Set Up Unattended-Upgrades
- Install:
apt install unattended-upgrades. - Edit config
/etc/apt/apt.conf.d/50unattended-upgradesper your policy. - Create or modify
/etc/apt/apt.conf.d/20auto-upgradesto enable. - Run
unattended-upgrade --dry-run --debugto verify. - Check logs at
/var/log/unattended-upgrades/.
How to Set Up dnf-automatic on RHEL/CentOS/AlmaLinux
dnf install dnf-automatic Config /etc/dnf/automatic.conf:
[commands] upgrade_type = security apply_updates = yes random_sleep = 360 [emitters] emit_via = email systemctl enable --now dnf-automatic-install.timer The timer runs daily with a random delay up to 360 seconds to spread the load on mirrors.
Which Packages Should Be Excluded from Automatic Updates?
Linux kernel, proprietary drivers (NVIDIA, AMD), and packages requiring manual migration (e.g., databases) should not be updated automatically. Use apt-mark hold <package> on Debian/Ubuntu or dnf versionlock <package> on RHEL. Unattended-Upgrades and dnf-automatic ignore locked packages. In our practice, hold packages are documented in Ansible inventory and verified at each deployment.
How to Verify Update Success?
On Debian/Ubuntu, check /var/log/unattended-upgrades/unattended-upgrades.log. On RHEL, journalctl -u dnf-automatic-install. If logs show kept back, it means dependency changes or active hold. A dry-run with unattended-upgrade --dry-run --debug shows what would be installed without applying.
Tool Comparison Across OS
| Parameter | Unattended-Upgrades | yum-cron / dnf-automatic |
|---|---|---|
| Debian/Ubuntu | ✅ | ❌ |
| RHEL/CentOS/AlmaLinux | ❌ | ✅ |
| Update type | security, updates, proposed | security, all |
| Notifications | email (on-change) | email, MQTT, script |
| Reboot delay | via config | via random_sleep |
| APT/YUM integration | full | full |
Our Work Stages for Configuring Patching
| Stage | Duration | Result |
|---|---|---|
| Audit current state | 1–2 hours | List of servers, OS, hold packages |
| Policy design | 1 hour | Update source, schedule, notifications |
| Implementation (Ansible role) | 2–4 hours | Playbook with configs for all OSes |
| Staging test | 1–2 hours | Verify updates without production impact |
| Production rollout | 1 hour | Gradual deployment with monitoring |
| Documentation | 1 hour | Hold packages, logs, rollback procedure |
Typical Mistakes in Automatic Patching
- Forgetting to exclude the kernel — server may reboot at an inconvenient time.
- Not setting up notifications — missing update failures.
- Using the same config for all OSes, ignoring differences between APT and DNF.
What's Included in the Automatic Patching Setup
- Current state audit: OS inventory, versions, hold packages.
- Update policy development: security-only, schedule, notifications.
- Writing an Ansible role for deploying configs to all servers.
- Testing on an isolated staging environment.
- Gradual production deployment with log monitoring.
- Documentation: hold packages, rollback procedure, admin instructions.
- Post-installation support: assistance during first update cycles.
How Long Does Setup Take?
For homogeneous infrastructure (only Debian or only RHEL) — from 2 hours. For mixed with different OSes and requirements — up to 1 day. Cost is calculated individually based on server count and complexity. You save administrator time and money that can be directed to development. The investment pays off by preventing incidents.
Assess your infrastructure in one day. Contact us for a consultation. Order automatic patching setup — get protection without downtime. Over 5 years of experience, 100+ projects, 500+ managed servers, certified engineers.