Linux Server Administration Checklist for Ubuntu, Debian, and AlmaLinux

I follow a strict routine on every new VPS to keep my systems secure and predictable. This is my linux server administration checklist for provisioning, securing and maintaining each node, whether it runs Debian, Ubuntu, or AlmaLinux instances.

Initial System Provisioning and User Management

When I first spin up a fresh server instance, I never leave it running on the default configuration. Root access should be strictly managed, and administrative tasks must be delegated through dedicated user accounts using secure shell keys.

Creating Sudoers and Disabling Root Login

I begin by logging into the server via the temporary root account or provider-supplied console. I create a new user with administrative privileges and assign a strong password:

adduser sysadmin
usermod -aG sudo sysadmin  # Use 'wheel' group on AlmaLinux

Next, I lock down SSH access to prevent direct root logins and password-based authentication. I open the SSH daemon configuration file:

sudo nano /etc/ssh/sshd_config

I make sure the following parameters are set explicitly:

PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
MaxAuthTries 3

I restart the SSH service to apply changes. On Ubuntu and Debian, I run sudo systemctl restart ssh, while on AlmaLinux I run sudo systemctl restart sshd. If I am configuring a custom home lab setup or experimenting with local networking gear, I might encounter unexpected throughput bottlenecks similar to troubleshooting issues discussed when analyzing why my 300 Mbps router shows only 144 Mbps on Wi-Fi, so I always verify my physical or virtual network interfaces are negotiating at maximum speed before deploying production services.

Configuring System Firewalls

Network security starts at the perimeter. I close unused ports and define traffic rules explicitly. Linux server administration workflows differ slightly depending on whether the distribution uses Debian-based utilities or Red Hat-based wrappers.

Managing UFW on Ubuntu and Debian

For Ubuntu and Debian environments, Uncomplicated Firewall (UFW) provides a straightforward management layer over netfilter:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Managing Firewalld on AlmaLinux

For AlmaLinux distributions, firewalld is my default zone-based packet filtering tool:

sudo systemctl start firewalld
sudo systemctl enable firewalld
sudo firewall-cmd --permanent --set-default-zone=public
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

I verify active rules using sudo ufw status verbose or sudo firewall-cmd --list-all depending on the operating system.

Package Management and System Updates

Keeping the software stack patched is a fundamental pillar of linux server administration. Unpatched vulnerabilities are the primary entry point for automated malware and targeted exploits.

Debian and Ubuntu (APT)

I update local package indexes and upgrade installed system packages safely:

sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y && sudo apt clean

To automate critical security patches without manual intervention, I install and configure the unattended-upgrades package:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

AlmaLinux (DNF)

For enterprise RPM-based systems, I use the DNF package manager:

sudo dnf upgrade --refresh -y

For automated security updates on AlmaLinux, I install the dnf-automatic utility:

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

Log Monitoring and Resource Troubleshooting

When applications throw errors or system performance degrades, log files and resource metrics provide the diagnostic trail I need to resolve incidents quickly.

Essential Diagnostic Commands

I rely on native utilities to inspect the real-time system state:

• htop or top: Monitor CPU, memory, and running process tables interactively.
• df -h: Check available disk space across mounted filesystems.
• free -m: Inspect RAM and swap utilization.
• journalctl -u nginx.service -e: View systemd journal entries for specific services.

If I am managing resource-constrained environments — such as optimizing lightweight hardware deployments or evaluating single-board computers like those analyzed in Raspberry Pi vs Orange Pi, keeping a close eye on memory pressure using vmstat or sar prevents unexpected out-of-memory crashes.

My setup

On my personal and client servers, I always stick to a minimal install of Ubuntu 24.04 LTS or AlmaLinux 9. I disable password authentication for SSH immediately, rely entirely on Ed25519 SSH keys, and configure UFW or firewalld before opening any web ports. For PHP applications, I usually pair Nginx 1.24 with PHP-FPM and restrict socket access tightly. I don't bother with heavy GUI panels on production boxes because CLI tools give me faster feedback and consume fewer system resources.

What went wrong (gotchas)

I have seen plenty of self-inflicted outages over the years by missing simple details during server hardening. Here are the common traps I watch out for:

• Forgetting to test the new SSH key configuration in a separate terminal window before closing the active session, which frequently locks you out of the VPS.
• Leaving SELinux in enforcing mode on AlmaLinux without adjusting file contexts for custom web root paths, resulting in unexpected 403 Forbidden errors.
• Forgetting to run sudo systemctl reload nginx after updating virtual host configurations.
• Setting incorrect file permissions on Laravel storage and bootstrap/cache directories, which breaks write operations and throws cryptic error logs.