[{"data":1,"prerenderedAt":183},["ShallowReactive",2],{"seo-verification":3,"blog-vps-automatic-security-updates-debian-ubuntu-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-vps-automatic-security-updates-debian-ubuntu-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":123,"ctaBody":124,"ctaButton":125,"ctaUrl":126,"relatedPosts":127},382,"vps-automatic-security-updates-debian-ubuntu",{"fr":12,"en":10,"ar":13,"es":14},"securite-vps-mises-a-jour-automatiques-debian-ubuntu","تحديثات-أمان-تلقائية-vps-debian-ubuntu","actualizaciones-seguridad-vps-debian-ubuntu","Automatic Security Updates on Debian\u002FUbuntu VPS","Configure unattended-upgrades on your Debian\u002FUbuntu VPS to automate security patches and reduce attack surface across your client fleet.",10,0,false,"2026-09-26T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu-poster.svg","A VPS exposed to the internet without an update policy is an open attack surface. Critical vulnerabilities are exploited within hours of a CVE being published, long before any manual intervention is possible. Configuring **unattended-upgrades** on every Debian or Ubuntu server in your fleet is the simplest way to mechanically reduce that exposure window, without giving up control over what gets applied.",[35,39,49,52,55,74,77,81,84,120],{"type":36,"title":37,"body":38},"h2","Why automate security patches","The lifecycle of a vulnerability is short. Between the publication of a critical CVE and the first mass exploitation attempts, the window is now measured in hours. For an agency managing ten, twenty, or fifty VPS instances, waiting for a scheduled manual intervention each week means offering several days of exposure on every machine.\n\nRegulation reinforces this requirement. The European **Cyber Resilience Act** requires operators of connected products to demonstrate a documented and enforced patch policy. For agencies hosting client applications, the absence of patch traceability may engage their contractual liability in the event of an incident.\n\nThe technical argument is straightforward: the majority of Linux server compromises exploit vulnerabilities for which a patch has been available for more than 30 days. The `unattended-upgrades` tool, included in Debian and Ubuntu repositories, automatically installs security patches from official repositories — without touching major version upgrades or packages you have explicitly excluded.",{"type":40,"title":41,"items":42},"ul","Concrete benefits for agencies managing a client fleet",[43,44,45,46,47,48],"**Reduced remediation time**: security patches are applied within hours of publication in stable repositories, without a maintenance ticket.","**Automatic traceability**: each installation is recorded in `\u002Fvar\u002Flog\u002Funattended-upgrades\u002F`, available at any time for an audit or client report.","**Controlled scope**: only updates labelled `security` are applied by default — version upgrades remain under manual control.","**Reduced operational burden**: a fleet of 50 VPS no longer requires 50 weekly SSH connections for `apt upgrade`.","**Documentable compliance**: the policy is defined in a versionable configuration file, reproducible via Ansible or any configuration management tool.","**Targeted notifications**: installation errors or required reboots can trigger an email, without flooding the team with routine reports.",{"type":36,"title":50,"body":51},"How unattended-upgrades works","`unattended-upgrades` is a Debian\u002FUbuntu daemon that runs via a `systemd` timer (or `cron` on older systems). It queries the configured APT repositories, filters packages according to the **allowed origins** defined in its configuration, then installs updates without user interaction.\n\nThe filtering logic relies on **APT Release files**. Each repository exposes metadata (`Origin`, `Suite`, `Codename`) that `unattended-upgrades` compares against its whitelist. By default on Ubuntu, only the `${distro_id}:${distro_codename}-security` origins are enabled — which corresponds exactly to the official Canonical security archives, without including backport updates or third-party packages.\n\nThe process runs in three phases: updating the APT cache (`apt-get update`), resolving dependencies for eligible packages, installing with detailed logging. In case of error (dependency conflict, locked package, insufficient disk space), the installation stops and a notification can be sent according to the configuration. System integrity is never compromised: `unattended-upgrades` never forces conflict resolution.",{"type":36,"title":53,"body":54},"Prerequisites","The configuration described in this article applies to **Debian 11\u002F12** and **Ubuntu 22.04\u002F24.04 LTS**. Older systems (Debian 10, Ubuntu 20.04) are compatible but their upstream support is approaching end of life — a migration is recommended before investing in their configuration.\n\nRequired access: SSH connection with `root` rights or a `sudo` account. No external dependencies are needed for basic operation; SMTP configuration is optional and only comes into play for email notifications.\n\nIf you manage your fleet with Ansible, the steps described below can be reproduced directly in a dedicated role — the configuration file structure is stable across major versions of Debian and Ubuntu.",{"type":56,"title":57,"steps":58},"steps","Install and configure unattended-upgrades",[59,62,65,68,71],{"title":60,"body":61},"Install the package","On Debian and Ubuntu, the package is available in standard repositories:\n\n```bash\napt-get update\napt-get install -y unattended-upgrades apt-listchanges\n```\n\nThe `apt-listchanges` package is optional but recommended: it allows including a change summary in email notifications.",{"title":63,"body":64},"Configure allowed origins","Edit `\u002Fetc\u002Fapt\u002Fapt.conf.d\u002F50unattended-upgrades`. The `Unattended-Upgrade::Allowed-Origins` section controls which repositories are eligible. On Ubuntu 22.04, the recommended minimal configuration:\n\n```\nUnattended-Upgrade::Allowed-Origins {\n    \"${distro_id}:${distro_codename}-security\";\n    \"${distro_id}ESMApps:${distro_codename}-apps-security\";\n    \"${distro_id}ESM:${distro_codename}-infra-security\";\n};\n```\n\nOn Debian 12, replace with:\n\n```\nUnattended-Upgrade::Allowed-Origins {\n    \"Debian:${distro_codename}-security\";\n};\n```\n\nTo exclude sensitive packages (for example a custom kernel or a pinned PHP version):\n\n```\nUnattended-Upgrade::Package-Blacklist {\n    \"linux-image\";\n    \"php8.2-fpm\";\n};\n```",{"title":66,"body":67},"Enable the periodic timer","The file `\u002Fetc\u002Fapt\u002Fapt.conf.d\u002F20auto-upgrades` controls execution frequency. Create it or verify its contents:\n\n```\nAPT::Periodic::Update-Package-Lists \"1\";\nAPT::Periodic::Unattended-Upgrade \"1\";\nAPT::Periodic::AutocleanInterval \"7\";\n```\n\nThe value `\"1\"` means daily execution. On Ubuntu, the `apt-daily-upgrade.timer` service is enabled automatically after this configuration. Check its status:\n\n```bash\nsystemctl status apt-daily-upgrade.timer\n```",{"title":69,"body":70},"Check the logs","Installation logs are written to `\u002Fvar\u002Flog\u002Funattended-upgrades\u002F`. The main file:\n\n```bash\ntail -50 \u002Fvar\u002Flog\u002Funattended-upgrades\u002Funattended-upgrades.log\n```\n\nA successful line looks like:\n\n```\n2026-09-25 04:12:31,847 INFO Packages that will be upgraded: libssl3 openssl\n2026-09-25 04:12:45,021 INFO Package libssl3 upgraded to 3.0.2-0ubuntu1.17\n```\n\nIn case of failure, the `unattended-upgrades-dpkg.log` file retains the full `dpkg` output for diagnosis.",{"title":72,"body":73},"Test on-demand execution","To trigger an immediate run without waiting for the timer and verify the configuration is operational:\n\n```bash\nunattended-upgrade --dry-run --debug 2>&1 | head -60\n```\n\nThe `--dry-run` option simulates installation without making any changes. Remove it for a real execution:\n\n```bash\nunattended-upgrade -v\n```\n\nIf the output shows `No packages found that can be upgraded unattended`, the system is up to date or no eligible package is waiting — this is the expected result on a recently provisioned server.",{"type":36,"title":75,"body":76},"Configuring email notifications","Email notifications allow the team to receive an alert when an update fails or when a reboot is required. They send nothing on silent success — which avoids flooding the inbox with daily reports.\n\nIn `\u002Fetc\u002Fapt\u002Fapt.conf.d\u002F50unattended-upgrades`, enable the option:\n\n```\nUnattended-Upgrade::Mail \"ops@your-agency.com\";\nUnattended-Upgrade::MailReport \"only-on-error\";\n```\n\nThe `only-on-error` value (recommended) only sends an email in case of error. The `on-change` value sends an email with each installation. The `always` value sends an email even when nothing is installed — avoid this on a fleet of several dozen machines.\n\nFor sending to work, the server must have a local MTA capable of relaying emails. On a minimal VPS, `postfix` in `satellite` mode is the lightest option:\n\n```bash\napt-get install -y postfix\n# Choose \"Satellite system\" in the wizard\n# Enter the SMTP relay of your provider or infrastructure\n```\n\nAlternatively, `msmtp` can serve as a relay to a transactional service (Mailgun, Postmark, SendGrid) without installing a full MTA.",{"type":78,"title":79,"body":80},"tip","Monitor required reboots with needrestart","Some security patches — especially those for the kernel, libc, or OpenSSL — require a reboot to be fully active. The `needrestart` tool detects services and processes still using the old versions in memory.\n\nInstall it with:\n\n```bash\napt-get install -y needrestart\n```\n\nAfter each update, `needrestart` lists the services to restart. In automatic mode (`$nrconf{restart} = 'a';` in `\u002Fetc\u002Fneedrestart\u002Fneedrestart.conf`), it restarts the affected services without intervention. For kernels, it never reboots the machine automatically without explicit configuration — this is the expected behavior on a production VPS.\n\nCombine `needrestart` with `unattended-upgrades` notifications: an email indicating that a reboot is required allows the team to schedule the intervention at the right time, without urgency but without delay.",{"type":36,"title":82,"body":83},"Automatic reboot for kernel patches","Automatic reboot after a kernel patch is the most delicate decision in an update policy. It ensures the fix is active immediately, but it interrupts running services — which may be unacceptable for certain workloads.\n\nIn `\u002Fetc\u002Fapt\u002Fapt.conf.d\u002F50unattended-upgrades`, the relevant options:\n\n```\nUnattended-Upgrade::Automatic-Reboot \"true\";\nUnattended-Upgrade::Automatic-Reboot-WithUsers \"false\";\nUnattended-Upgrade::Automatic-Reboot-Time \"03:00\";\n```\n\n`Automatic-Reboot-Time` schedules the reboot at an off-peak hour. `Automatic-Reboot-WithUsers \"false\"` prevents rebooting if a user session is open — useful for development machines, less relevant for a production server without permanent interactive connections.\n\n**Essential precautions before enabling this option**:\n- Verify that your services restart automatically at boot (`systemctl is-enabled \u003Cservice>`).\n- Test the full reboot time on a staging server before deploying to production.\n- If your application requires a specific startup order (database before application), document and test this scenario.\n- For a multi-VPS fleet, stagger reboot times — see the next section.",{"type":85,"title":86,"headers":87,"rows":91},"comparison","Manual vs automatic updates: comparison",[88,89,90],"Criterion","Manual update","Automatic update (unattended-upgrades)",[92,96,100,104,108,112,116],[93,94,95],"Application delay","Depends on maintenance schedule — often 3 to 7 days","A few hours after publication in stable repositories",[97,98,99],"Traceability","Depends on the thoroughness of maintenance notes","Automatic timestamped log in `\u002Fvar\u002Flog\u002Funattended-upgrades\u002F`",[101,102,103],"Regression risk","Controlled: each update is validated before application","Low on stable security patches, mitigated by blacklist",[105,106,107],"Operational burden","High on a fleet of more than 5 VPS","Negligible once the configuration is deployed",[109,110,111],"Active kernel patches","Immediate if reboot is scheduled","Requires automatic reboot configuration or manual intervention",[113,114,115],"Critical CVE coverage","Insufficient if the cycle is weekly","Optimal — patches are applied in the narrowest possible window",[117,118,119],"Documentable compliance","Difficult to prove without additional tooling","Log files and versionable, auditable configuration",{"type":36,"title":121,"body":122},"Deploy and manage unattended-upgrades across a multi-VPS fleet","The configuration described so far applies to a single server. For a fleet of dozens of client VPS instances, reproducibility and coordination become challenges in their own right.\n\n**Automate with Ansible**\n\nA simple Ansible role is sufficient to deploy the configuration across the entire fleet in minutes. Store the `50unattended-upgrades` and `20auto-upgrades` files in `templates\u002F` and make reboot options configurable via inventory variables:\n\n```yaml\n- name: Deploy unattended-upgrades\n  hosts: vps_clients\n  become: true\n  tasks:\n    - name: Install unattended-upgrades\n      apt:\n        name: [unattended-upgrades, apt-listchanges]\n        state: present\n        update_cache: true\n    - name: Deploy configuration\n      template:\n        src: 50unattended-upgrades.j2\n        dest: \u002Fetc\u002Fapt\u002Fapt.conf.d\u002F50unattended-upgrades\n        owner: root\n        mode: '0644'\n    - name: Deploy apt-periodic\n      copy:\n        src: 20auto-upgrades\n        dest: \u002Fetc\u002Fapt\u002Fapt.conf.d\u002F20auto-upgrades\n        owner: root\n        mode: '0644'\n```\n\n**Stagger reboots**\n\nIf automatic reboot is enabled, do not configure the same time on all your servers. A simultaneous reboot of 30 VPS can generate unusual reconnection load on your infrastructure and complicate diagnosis if problems arise. Distribute times over a two-hour window (`02:00` to `04:00`) using an Ansible variable per group or per server.\n\n**Test on staging before the production fleet**\n\nFor configurations that enable automatic reboot or modify the package blacklist, validate first on a representative staging server. A VPS at 99 DH\u002Fmonth dedicated to configuration testing avoids propagating a configuration error across the entire fleet.\n\n**Centralize alerts**\n\nRather than receiving individual emails from each server, configure an email alias that aggregates alerts into a single monitoring channel. If your infrastructure already uses a log aggregator (Loki, OpenSearch), `unattended-upgrades` log files can be forwarded there via a lightweight agent for a centralized fleet view.\n\nFor more on securing your VPS, see our \u003Ca href=\"\u002Fblog\u002Flinux-hardening-vps-checklist\">Linux hardening checklist\u003C\u002Fa> and our \u003Ca href=\"\u002Fblog\u002Fcrowdsec-vs-fail2ban-securite-vps\">CrowdSec vs Fail2ban comparison\u003C\u002Fa>. If you also manage self-hosted applications, the \u003Ca href=\"\u002Fblog\u002Froutine-correctifs-apps-self-hosted\">self-hosted application patch routine\u003C\u002Fa> complements this approach with the application layers.","Manage a client VPS fleet without friction","ServOrbit.com offers managed VPS from 99 DH\u002Fmonth, with automated provisioning and a centralized dashboard for agencies and resellers.","Manage my VPS fleet","\u002Fsolutions\u002Fagences",[128,145,168],{"id":129,"slug":130,"slugs":131,"title":135,"excerpt":136,"readTime":137,"views":138,"isPinned":19,"publishedAt":139,"updatedAt":140,"category":141,"categories":142,"featuredImage":30,"bgImage":31,"posterImage":144,"relatedSolution":30},317,"linux-vps-hardening-checklist-for-agencies",{"fr":132,"en":130,"ar":133,"es":134},"linux-hardening-vps-checklist","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","hardening-linux-vps-checklist-para-agencias-tras-la-entrega","Linux VPS Hardening Checklist for Agencies","Reproducible Linux hardening checklist for agencies: auditd, sudo user, SSH key auth, UFW, fail2ban and root lockout — with per-client traceability.",11,1,"2026-08-30T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[143],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg",{"id":146,"slug":147,"slugs":148,"title":152,"excerpt":153,"readTime":154,"views":155,"isPinned":19,"publishedAt":156,"updatedAt":157,"category":158,"categories":163,"featuredImage":30,"bgImage":31,"posterImage":165,"relatedSolution":166},348,"crowdsec-vs-fail2ban-which-to-choose-for-your-vps",{"fr":149,"en":147,"ar":150,"es":151},"crowdsec-vs-fail2ban-securite-vps","crowdsec-مقابل-fail2ban-ايهما-تختار-لخادمك","crowdsec-vs-fail2ban-cual-elegir-para-tu-vps","CrowdSec vs Fail2ban: Which One to Choose for Your VPS","CrowdSec or Fail2ban on your Linux VPS? Comparison by use case: community blocklist or local simplicity — the decision tree to choose the right tool.",7,3,"2026-09-11T00:00:00+00:00","2026-09-11T11:34:13+00:00",{"id":159,"name":160,"slug":161,"color":162,"icon":161},5,"Comparison","comparatif","bg-info\u002F10 text-info",[164],{"id":159,"name":160,"slug":161,"color":162,"icon":161},"\u002Fblog\u002Fcovers\u002Fcrowdsec-vs-fail2ban-securite-vps-poster.svg",{"categorySlug":167,"appSlug":30},"cybersecurity-bastion",{"id":169,"slug":170,"slugs":171,"title":175,"excerpt":176,"readTime":177,"views":138,"isPinned":19,"publishedAt":178,"updatedAt":140,"category":179,"categories":180,"featuredImage":30,"bgImage":31,"posterImage":182,"relatedSolution":30},224,"self-hosted-apps-the-patching-routine",{"fr":172,"en":170,"ar":173,"es":174},"routine-correctifs-apps-self-hosted","التطبيقات-المستضافة-ذاتيا-روتين-التصحيحات","apps-self-hosted-rutina-de-parches","Self-hosted apps: the patching routine","Inventory, security advisories, a patch window, backups and post-checks: the routine most self-hosted estates are missing.",4,"2026-08-05T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[181],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Froutine-correctifs-apps-self-hosted-poster.svg",1790693284695]