BLOG POSTS

MangoHost Blog / How to Keep Ubuntu 24 Servers Updated

How to Keep Ubuntu 24 Servers Updated

Keeping your Ubuntu 24 servers properly updated is one of those essential tasks that separates reliable infrastructure from the kind that fails at 3 AM on a Friday. This isn’t just about security patches (though those are critical) – it’s about maintaining system stability, getting performance improvements, and avoiding the technical debt that accumulates when you let updates slide. We’ll walk through the complete toolkit for managing Ubuntu 24 updates, from basic manual commands to sophisticated automated strategies that won’t break your production environment.

Understanding Ubuntu 24 Update Mechanisms

Ubuntu 24 uses APT (Advanced Package Tool) as its primary package management system, but there’s more going on under the hood than just apt update && apt upgrade. The system distinguishes between different types of updates through various repositories and update channels.

The update ecosystem consists of several key components:

Security updates: Critical patches delivered through the security repository
Standard updates: Bug fixes and minor improvements from the updates repository
Proposed updates: Pre-release updates for testing (disabled by default)
Backports: Newer software versions backported from newer Ubuntu releases

Ubuntu 24 also introduces enhanced support for snap packages and improved integration with unattended-upgrades, making automated updating more reliable than previous versions.

Manual Update Process and Commands

Let’s start with the foundation – manual updates. Even if you plan to automate everything, understanding the manual process is crucial for troubleshooting.

The basic update sequence:

# Update package lists
sudo apt update

# Show available upgrades
apt list --upgradable

# Perform safe upgrades
sudo apt upgrade

# Full system upgrade (handles dependencies more aggressively)
sudo apt full-upgrade

# Clean up unnecessary packages
sudo apt autoremove
sudo apt autoclean

For more granular control, you can target specific packages or repositories:

# Update only security packages
sudo apt upgrade -s | grep -i security

# Upgrade specific package
sudo apt install --only-upgrade package-name

# Hold a package from updates
sudo apt-mark hold package-name

# Show held packages
apt-mark showhold

The difference between upgrade and full-upgrade is important: upgrade will never remove packages or install new ones, while full-upgrade can install new dependencies or remove conflicting packages. In production, you usually want upgrade for safety.

Automated Updates with Unattended-Upgrades

Manual updates don’t scale, and they’re prone to human error (or human forgetfulness). Ubuntu 24’s unattended-upgrades package provides robust automation with fine-grained control.

Installation and basic setup:

# Install unattended-upgrades
sudo apt install unattended-upgrades

# Enable automatic updates
sudo dpkg-reconfigure -plow unattended-upgrades

The main configuration file is /etc/apt/apt.conf.d/50unattended-upgrades. Here’s a production-ready configuration:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}:${distro_codename}-updates";
    // "${distro_id}:${distro_codename}-proposed";  // Don't enable this in production
};

// Packages to never automatically upgrade
Unattended-Upgrade::Package-Blacklist {
    "nginx";
    "apache2";
    "mysql-server";
    "postgresql";
};

// Automatically remove unused dependencies
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// Automatically reboot if required
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

// Email notifications
Unattended-Upgrade::Mail "admin@yourdomain.com";
Unattended-Upgrade::MailOnlyOnError "true";

// Keep detailed logs
Unattended-Upgrade::SyslogEnable "true";
Unattended-Upgrade::SyslogFacility "daemon";

For the update schedule, configure /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

Testing and Dry-Run Strategies

Before applying updates to production systems, you need reliable testing strategies. Ubuntu 24 provides several tools for this.

Dry-run commands to see what would happen:

# Simulate upgrade without actually doing it
sudo apt upgrade -s

# Test unattended-upgrades configuration
sudo unattended-upgrade --dry-run --debug

# Check what packages would be upgraded by unattended-upgrades
sudo unattended-upgrades --debug --dry-run

For more comprehensive testing, consider using LXD containers or VMs that mirror your production environment:

# Create test container
lxc launch ubuntu:24.04 test-updates

# Copy your production configuration
lxc file push /etc/apt/ test-updates/etc/apt/ -r

# Enter container and test updates
lxc exec test-updates -- bash
apt update && apt upgrade -s

Monitoring and Logging Update Activities

Visibility into your update process is crucial for maintaining reliability. Ubuntu 24 provides several logging mechanisms:

Key log files to monitor:

/var/log/unattended-upgrades/unattended-upgrades.log – Main unattended-upgrades log
/var/log/apt/history.log – APT transaction history
/var/log/apt/term.log – Detailed APT output
/var/log/dpkg.log – Low-level package management log

Set up log rotation to prevent disk space issues:

# Create logrotate configuration
sudo tee /etc/logrotate.d/unattended-upgrades << EOF
/var/log/unattended-upgrades/*.log {
    daily
    missingok
    rotate 52
    compress
    notifempty
    create 640 root adm
}
EOF

For real-time monitoring, you can use tools like this simple script:

#!/bin/bash
# update-monitor.sh - Simple update monitoring script

LOG_FILE="/var/log/unattended-upgrades/unattended-upgrades.log"
WEBHOOK_URL="https://your-monitoring-service.com/webhook"

# Monitor for successful updates
tail -F "$LOG_FILE" | while read line; do
    if echo "$line" | grep -q "INFO Packages that will be upgraded"; then
        echo "$(date): Updates detected - $line"
        # Send notification to monitoring system
        curl -X POST "$WEBHOOK_URL" -d "Updates detected on $(hostname): $line"
    fi
done

Comparison of Update Strategies

Different environments require different update approaches. Here's a comparison of common strategies:

Strategy	Best For	Automation Level	Risk Level	Maintenance Overhead
Manual Updates	Critical production systems	None	Low (if done regularly)	High
Security-Only Auto	Production web servers	Medium	Low	Medium
Full Auto Updates	Development/staging	High	Medium	Low
Scheduled Maintenance	Enterprise environments	Medium	Low	Medium

Handling Kernel Updates and Reboots

Kernel updates are special because they require reboots to take effect. Ubuntu 24 includes improved tools for managing this process.

Check if reboot is required:

# Check reboot requirement
if [ -f /var/run/reboot-required ]; then
    echo "Reboot required"
    cat /var/run/reboot-required.pkgs
else
    echo "No reboot required"
fi

# Alternative method using needrestart
sudo needrestart -k

For automated reboot management, you can use this script approach:

#!/bin/bash
# smart-reboot.sh - Conditional reboot script

MAINTENANCE_WINDOW_START="02:00"
MAINTENANCE_WINDOW_END="04:00"
CURRENT_TIME=$(date +"%H:%M")

if [ -f /var/run/reboot-required ]; then
    echo "Reboot required for packages:"
    cat /var/run/reboot-required.pkgs
    
    # Check if we're in maintenance window
    if [[ "$CURRENT_TIME" > "$MAINTENANCE_WINDOW_START" && "$CURRENT_TIME" < "$MAINTENANCE_WINDOW_END" ]]; then
        echo "In maintenance window, rebooting in 60 seconds..."
        /usr/bin/logger "Automated reboot initiated for package updates"
        shutdown -r +1 "Rebooting for system updates"
    else
        echo "Outside maintenance window, reboot postponed"
        # Send notification instead
        echo "System requires reboot but outside maintenance window" | mail -s "Reboot Required: $(hostname)" admin@yourdomain.com
    fi
fi

Security Considerations and Best Practices

Update security goes beyond just applying patches - you need to ensure your update process itself is secure and reliable.

Essential security practices:

Verify GPG signatures: Ensure APT is configured to verify package signatures
Use HTTPS repositories: Configure secure transport for package downloads
Staged deployments: Test updates in staging before production
Backup before major updates: Always have a rollback plan
Monitor for unauthorized changes: Use tools like AIDE or Tripwire

Secure APT configuration in /etc/apt/apt.conf.d/99security:

// Require GPG signature verification
APT::Get::AllowUnauthenticated "false";

// Use secure transport
Acquire::https::Verify-Peer "true";
Acquire::https::Verify-Host "true";

// Timeout settings to prevent hanging
Acquire::http::Timeout "10";
Acquire::https::Timeout "10";

// Retry settings
Acquire::Retries "3";

Troubleshooting Common Update Issues

Even with perfect planning, updates sometimes go wrong. Here are the most common issues and their solutions:

Broken packages after upgrade:

# Fix broken packages
sudo apt --fix-broken install

# Reconfigure packages
sudo dpkg --configure -a

# Force package installation if needed (use carefully)
sudo apt install -f

Held packages preventing upgrades:

# List held packages
apt-mark showhold

# Unhold specific package
sudo apt-mark unhold package-name

# Unhold all packages (dangerous in production)
sudo apt-mark unhold $(apt-mark showhold)

Repository issues:

# Clear APT cache
sudo apt clean
sudo apt autoclean

# Reset repository lists
sudo rm /var/lib/apt/lists/* -vf
sudo apt update

# Check repository accessibility
sudo apt update 2>&1 | grep -i "failed\|error"

Disk space issues during updates:

# Clean package archives
sudo apt autoremove
sudo apt autoclean

# Remove old kernels (keep current + 1 previous)
sudo apt autoremove --purge

# Find large log files
sudo find /var/log -type f -size +100M -exec ls -lh {} \;

Integration with Configuration Management

For larger deployments, integrate update management with configuration management tools. Here's an Ansible playbook example:

---
- name: Ubuntu 24 Update Management
  hosts: ubuntu_servers
  become: yes
  tasks:
    - name: Update apt cache
      apt:
        update_cache: yes
        cache_valid_time: 3600

    - name: Install unattended-upgrades
      apt:
        name: unattended-upgrades
        state: present

    - name: Configure unattended-upgrades
      template:
        src: 50unattended-upgrades.j2
        dest: /etc/apt/apt.conf.d/50unattended-upgrades
        backup: yes
      notify: restart unattended-upgrades

    - name: Upgrade security packages only
      apt:
        upgrade: safe
        update_cache: yes
      when: security_updates_only | default(false)

    - name: Check if reboot required
      stat:
        path: /var/run/reboot-required
      register: reboot_required

    - name: Notify about reboot requirement
      debug:
        msg: "Reboot required on {{ inventory_hostname }}"
      when: reboot_required.stat.exists

This approach allows you to maintain consistent update policies across your entire infrastructure while still providing flexibility for different server roles.

For more detailed information about Ubuntu package management, check the official Ubuntu APT documentation and the Debian unattended-upgrades guide.

Remember that update management is an ongoing process, not a one-time setup. Regular review of your update logs, testing procedures, and automation rules will help you maintain a secure and stable server environment. The key is finding the right balance between security, stability, and operational overhead for your specific use case.

This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.

This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.