Testing unattended-upgrades on a staging VM without production credentials, and deciding the automatic reboot policy

Answer to the core question

Running unattended-upgrade --dry-run --debug on a clean staging VM that mirrors the production Ubuntu LTS release is a reliable proxy for most upgrade-time decisions. It reproduces dependency resolution, package selection, and the log entries that would be written on a real run. However, it does not execute post-install scripts or detect runtime failures that only appear after packages are actually installed.

The Allowed-Origins filter and local mail reporting can be exercised entirely without external credentials; the mail sent by unattended-upgrades is delivered to the configured mailbox locally. Reboot behavior is governed by the three settings:

• Automatic-Reboot – enables a reboot after a kernel or other reboot-required package is installed.
• Automatic-Reboot-Time – forces a reboot at the specified time window, regardless of logged-in users.
• Automatic-Reboot-WithUsers – defers the reboot until no users are logged in.

Confirmed facts (based on current Ubuntu behaviour)

• Dry-run logs all actions that would be taken, including which packages would be installed and whether a reboot is required.
• Mail notifications are written to the local mailbox configured in /etc/apt/apt.conf.d/50unattended-upgrades without needing external SMTP credentials.
• The log file /var/log/unattended-upgrades/unattended-upgrades.log contains the same information as the debug output.
• Automatic-Reboot settings are applied only after the upgrade process completes; they do not influence package selection.

Suggested test plan for the staging VM

1. Prepare the environment
   • Spin up a fresh VM with the same Ubuntu LTS release as production.
   • Mirror the /etc/apt/sources.list entries (no internal mirrors that require authentication).
   • Install the unattended-upgrades package if not already present.
2. Configure unattended-upgrades
   • Set Unattended-Upgrade::Allowed-Origins to "${distro_id}:${distro_codename}-security".
   • Set Unattended-Upgrade::Mail to a local mailbox (e.g., root or a dedicated user).
   • Populate Unattended-Upgrade::Package-Blacklist with "linux-image-*" to hold back kernels.
   • Leave Automatic-Reboot disabled for the dry-run phase.
3. Run a dry-run

   sudo unattended-upgrade --dry-run --debug | tee /tmp/ur-dryrun.log
   

   • Verify that the list of packages to be installed matches the entries in /var/log/unattended-upgrades/unattended-upgrades.log.
   • Check that the log indicates no reboot would be required because the kernel is blacklisted.
4. Validate mail delivery
   • Check the local mailbox for a notification email that mirrors the log content.
5. Enable real upgrades and observe reboot behavior
   • Set Automatic-Reboot to true and choose a policy that matches your maintenance window strategy.
   • Optional: enable Automatic-Reboot-WithUsers if you prefer to avoid reboots while users are logged in.
   • Run sudo unattended-upgrade and watch for the system to reboot at the configured time or after all users log out.
   • After reboot, verify that services restart correctly and that the kernel version matches the upgraded one.
6. Document findings
   • Record the dry-run output, the real-run log, and the final system state for future reference.

Criteria for automatic-reboot policy

• Service criticality – If the server hosts a service that must be available 24/7, a scheduled reboot during a low-traffic window is preferable.
• Downtime cost – Estimate the impact of a brief outage; if the cost is acceptable, enable Automatic-Reboot with a fixed time window.
• User presence – If the machine is frequently used interactively, Automatic-Reboot-WithUsers helps avoid disrupting logged-in sessions.
• Maintenance window availability – When a well-defined window exists, use Automatic-Reboot-Time to guarantee a reboot at that slot.
• Custom packages or services – If production includes custom kernel modules or services that require special handling, test those on staging before deciding.

Missing diagnostic detail that could change the recommendation

Does production use any custom kernel packages or services that are absent from the staging VM?