How To Do Patching In Linux Server : Linux Server Security Updates

by

Securing your Linux server against vulnerabilities begins with a consistent schedule for applying system updates. This guide covers exactly how to do patching in linux server environments, from basic commands to advanced automation strategies. You’ll learn practical steps to keep your server safe without breaking critical services.

Patching isn’t just about running a command. It’s about understanding your system, testing updates, and rolling back if something goes wrong. Let’s start with the fundamentals.

Why Patching Matters For Linux Server Security

Every day, security researchers find new vulnerabilities in Linux kernels, libraries, and applications. Attackers actively scan for unpatched systems. A single missed update can lead to data breaches, ransomware, or complete system compromise.

Patching fixes known bugs, closes security holes, and improves stability. It’s the single most effective way to protect your server. But many administrators skip patches because they fear downtime or compatibility issues. With proper planning, those risks are minimal.

Prerequisites Before You Start Patching

Before you run any update commands, take these steps to protect yourself:

  • Backup critical data and configuration files
  • Create a system snapshot if using virtualization
  • Note current kernel and package versions
  • Ensure you have root or sudo access
  • Check disk space – updates need room to download
  • Plan for a maintenance window if rebooting

Having a rollback plan is non-negotiable. If a patch breaks your application, you need to recover fast. More on that later.

How To Do Patching In Linux Server

Now let’s get into the actual process. The exact steps depend on your distribution, but the core concepts are the same.

Check Your Current System Status

First, see what packages are installed and which have updates available. This gives you a clear picture before making changes.

For Debian/Ubuntu systems:

sudo apt update
sudo apt list --upgradable

For RHEL/CentOS/Fedora:

sudo yum check-update
# or for newer versions
sudo dnf check-update

Review the list. Look for kernel updates, security patches, and library upgrades. Pay attention to packages your application depends on.

Apply Security Updates Only

Sometimes you want to patch just the critical vulnerabilities without upgrading everything. This reduces risk while still protecting your server.

On Debian/Ubuntu:

sudo apt upgrade --only-upgrade
# Or use unattended-upgrades for automatic security patches

On RHEL/CentOS:

sudo yum update --security
# For dnf:
sudo dnf update --security

Security-only updates are safer because they don’t introduce new features that might break things. Use this approach for production servers during business hours.

Apply All Available Updates

For a full system patch, run the complete update command. This updates all packages to their latest versions.

Debian/Ubuntu:

sudo apt upgrade

RHEL/CentOS/Fedora:

sudo yum update
# or
sudo dnf upgrade

The process downloads and installs packages. You’ll see progress bars and prompts for configuration file changes. Read those prompts carefully – sometimes you need to choose between keeping your config or using the new one.

Handle Kernel Updates Carefully

Kernel updates are special. They require a reboot to take effect. But rebooting means downtime.

Check if a kernel update was installed:

# See current kernel version
uname -r

# Check if new kernel packages are installed
# Debian/Ubuntu:
dpkg -l | grep linux-image

# RHEL/CentOS:
rpm -qa | grep kernel

If you have multiple kernels installed, the newest one will boot by default after reboot. You can delay the reboot if needed, but don’t wait too long – the vulnerability remains until you restart.

Reboot When Required

After kernel updates, reboot the server:

sudo reboot

For services that don’t require a full reboot, restart them individually:

sudo systemctl restart nginx
sudo systemctl restart sshd

Check service status after restart:

sudo systemctl status nginx

Make sure everything is running normally before declaring success.

Automated Patching Strategies

Manual patching is fine for a few servers. But if you manage many machines, automation saves time and reduces human error.

Using Unattended-Upgrades (Debian/Ubuntu)

This tool automatically installs security updates daily. It’s simple to set up:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Configure which updates to apply automatically in /etc/apt/apt.conf.d/50unattended-upgrades. You can choose security updates only, or include all updates.

Using Dnf Automatic (RHEL/Fedora)

Similar tool for Red Hat-based systems:

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

Edit /etc/dnf/automatic.conf to control behavior. You can set it to only download updates, or download and install them.

Using Cron Jobs For Custom Scripts

Write a simple script that runs updates and logs results:

#!/bin/bash
# /usr/local/bin/patch-server.sh
apt update && apt upgrade -y >> /var/log/patch.log 2>&1
reboot

Add it to crontab:

0 2 * * 0 /usr/local/bin/patch-server.sh

This runs every Sunday at 2 AM. Adjust timing based on your maintenance window.

Testing Patches Before Deployment

Never patch production servers without testing first. Even security updates can cause issues.

Set Up A Staging Environment

Clone your production server configuration in a test environment. Apply patches there first. Monitor for:

  • Service failures
  • Performance degredation
  • Application errors
  • Configuration conflicts

If everything passes, proceed to production. This adds hours to your process but saves days of troubleshooting later.

Use Canary Deployments

Patch one server first, then monitor it for 24-48 hours. If no issues arise, patch the rest. This is especially useful in load-balanced environments.

Rolling Back A Bad Patch

Sometimes a patch causes problems. You need to revert quickly.

Debian/Ubuntu Rollback

APT doesn’t have a built-in rollback. You need to manually downgrade packages:

# Find previous version in apt history
sudo grep " install " /var/log/dpkg.log

# Downgrade specific package
sudo apt install package-name=previous-version

Better approach: use snapshots. If you took a filesystem snapshot before patching, restore it.

RHEL/CentOS Rollback

YUM and DNF keep transaction history:

# List recent transactions
sudo yum history

# Undo a specific transaction
sudo yum history undo

This reverts all packages changed in that transaction. It’s reliable but can fail if dependencies changed.

Using Snapshots For Quick Recovery

If your server runs on a VM or cloud instance, take a snapshot before patching. If something breaks, restore the snapshot. This takes minutes instead of hours.

For physical servers, use LVM snapshots or filesystem-level backups.

Best Practices For Linux Patching

Follow these guidelines to keep your patching process smooth:

  • Patch regularly – at least monthly for security updates
  • Keep a change log of what was updated and when
  • Monitor vendor security advisories for critical vulnerabilities
  • Use a configuration management tool like Ansible or Puppet for consistency
  • Test patches in a non-production environment first
  • Have a rollback plan ready before starting
  • Reboot only during maintenance windows
  • Update your documentation after each patch cycle

Common Patching Pitfalls To Avoid

Even experienced admins make mistakes. Here are the most common ones:

  • Skipping updates because “it’s working fine” – that’s when you’re most vulnerable
  • Applying patches without reading release notes – some updates deprecate features
  • Forgetting to restart services after library updates – the old version stays in memory
  • Using apt upgrade instead of apt full-upgrade on Debian – sometimes dependencies require removal
  • Not checking disk space before updates – a full partition can break the update process
  • Ignoring configuration file prompts – always review what’s changing

Patching Different Linux Distributions

Each distribution has its own package manager and quirks. Here’s a quick reference:

Debian / Ubuntu

Uses APT (Advanced Package Tool). Commands:

sudo apt update
sudo apt upgrade
sudo apt full-upgrade  # handles dependency changes
sudo apt autoremove    # removes unused packages

RHEL / CentOS / Rocky Linux

Uses YUM or DNF. Commands:

sudo yum update
# or
sudo dnf upgrade
sudo dnf autoremove

Fedora

Uses DNF exclusively. Same commands as RHEL but with more frequent updates.

OpenSUSE

Uses Zypper. Commands:

sudo zypper refresh
sudo zypper update
sudo zypper patch  # security patches only

Arch Linux

Uses Pacman. Rolling release model means constant updates:

sudo pacman -Syu

Arch requires more attention because updates are frequent and sometimes breaking.

Monitoring Patch Status

After patching, verify everything is up to date:

# Check for pending updates
# Debian/Ubuntu:
sudo apt list --upgradable

# RHEL/CentOS:
sudo yum check-update

# Check reboot required
# Check if /var/run/reboot-required exists
cat /var/run/reboot-required

Use tools like needrestart on Debian to identify services that need restarting after library updates.

Advanced Patching Techniques

For large environments, consider these approaches:

Live Patching For Kernels

Tools like KernelCare, Ksplice, or Livepatch apply kernel security patches without rebooting. This eliminates downtime for critical servers.

Install Livepatch on Ubuntu:

sudo snap install canonical-livepatch
sudo canonical-livepatch enable

It’s not free for production, but it’s worth the cost for 24/7 services.

Using Ansible For Patching Multiple Servers

Ansible playbooks can patch hundreds of servers in one run. Example playbook:

---
- name: Patch all servers
  hosts: all
  tasks:
    - name: Update apt cache
      apt:
        update_cache: yes
      when: ansible_os_family == "Debian"

    - name: Upgrade all packages
      apt:
        upgrade: dist
      when: ansible_os_family == "Debian"

    - name: Reboot if kernel updated
      reboot:
        reboot_timeout: 300
      when: ansible_kernel is defined

This ensures consistency across your infrastructure.

Using Spacewalk Or Satellite

For RHEL environments, Red Hat Satellite provides centralized patch management. It gives you a dashboard, scheduling, and compliance reporting.

Frequently Asked Questions

How Often Should I Patch My Linux Server?

At minimum, apply security patches monthly. For critical vulnerabilities, patch within 24-48 hours of the advisory. Some organizations patch weekly for production servers.

Can I Patch A Linux Server Without Rebooting?

Most library and application updates don’t require a reboot. Kernel updates do, unless you use live patching tools. Restart affected services after library updates to apply changes.

What’s The Difference Between Apt Update And Apt Upgrade?

apt update refreshes the package list from repositories. apt upgrade actually installs the newer versions. You must run update first so your system knows what’s available.

How Do I Rollback A Bad Patch On Linux?

Use your package manager’s history (yum history undo) or restore from a snapshot. For APT, you need to manually downgrade packages. Always test patches first to avoid rollbacks.

Is It Safe To Automate Patching On Production Servers?

Yes, if you limit automation to security updates and test thoroughly. Use tools like unattended-upgrades with careful configuration. Always have monitoring and rollback procedures in place.

Conclusion

Patching your Linux server doesn’t have to be scary. With a clear process, testing, and rollback plans, you can keep your system secure without breaking things. Start with manual patching to learn the ropes, then move to automation as you gain confidence.

Remember: the worst patch is the one you never apply. A small downtime for updates is far better than a data breach from an unpatched vulnerability. Make patching a regular part of your server maintenance routine.

Now you know how to do patching in linux server from start to finish. Go ahead and run that first update – your server will thank you.