Ubuntu 24.04 Server Initialization and Maintenance Guide

Last reviewed: 2026-03-05

Target systems:

• Ubuntu Server 24.04 LTS
• Plesk Obsidian on Ubuntu 24.04 LTS
• production VPS, dedicated server, or cloud VM deployments

Ubuntu 24.04 LTS is security maintained for five years, through May 31, 2029. Ubuntu LTS releases are the safer default for production systems because they prioritize stability and long-term security maintenance. Ubuntu Documentation

This guide covers a practical baseline for initializing and maintaining an Ubuntu 24.04 server, including user setup, SSH hardening, firewall rules, automatic updates, Git and GitHub configuration, commit signing, Git LFS, LVM storage management, Plesk administration, MariaDB upgrades, and Acronis Backup Agent handling.

1. Update the server

After provisioning a new Ubuntu 24.04 server, update the package list and install available upgrades:

sudo apt update
sudo apt full-upgrade -y
sudo apt autoremove --purge -y
sudo apt autoclean

If a kernel or core system package was upgraded, reboot the server:

sudo reboot

After rebooting, confirm the OS version:

lsb_release -a
hostnamectl

2. Set hostname and timezone

Set a clear hostname:

sudo hostnamectl set-hostname server-name

Set the timezone:

sudo timedatectl set-timezone America/Los_Angeles
timedatectl

Check time synchronization:

timedatectl status

3. Create an administrator user

Many Ubuntu cloud images already create a default user such as ubuntu. If the server was provisioned with root access only, create a normal administrator user:

adduser anthony
usermod -aG sudo anthony

Test the new user:

su - anthony
sudo whoami

Expected output:

root

Use a normal sudo user for daily administration instead of logging in as root.

4. Configure SSH key login

On your local machine, generate an Ed25519 SSH key:

ssh-keygen -t ed25519 -C "hi@anth.dev"

GitHub's SSH documentation uses Ed25519 in its current key generation examples, and Ed25519 is a good default for new SSH keys. GitHub Docs

Copy the public key to the server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub anthony@server.example.com

If ssh-copy-id is unavailable, add the key manually on the server:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Paste the public key into authorized_keys.

Do not paste the private key. The private key stays on your local machine.

5. Harden SSH

Use a drop-in config file instead of editing the main SSH config directly:

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

Add:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Optional, if only specific users should be able to SSH into the server:

AllowUsers anthony

Validate the SSH configuration:

sudo sshd -t

Reload SSH:

sudo systemctl reload ssh

Keep your current terminal open and test a second SSH session before closing anything:

ssh anthony@server.example.com

PermitRootLogin controls whether root can log in using SSH, and PasswordAuthentication controls password-based SSH login. Setting both to no forces normal users to use key-based access. man7.org

6. Configure the firewall

Ubuntu's default firewall tool is ufw, which provides a simpler interface for managing firewall rules. Configure allowed services before enabling it. Ubuntu

Allow SSH first:

sudo ufw allow OpenSSH

For a normal web server:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Enable the firewall:

sudo ufw enable
sudo ufw status verbose

For a Plesk server, do not blindly allow only ports 80 and 443. Plesk panel access, updates, mail, DNS, FTP, and other hosting services may require additional ports depending on what the server actually runs.

Common Plesk panel ports:

sudo ufw allow 8443/tcp
sudo ufw allow 8447/tcp

Only open mail, DNS, FTP, database, or custom application ports when those services are intentionally hosted on the server.

7. Verify automatic security updates

Ubuntu Server uses unattended-upgrades for automatic security updates. Ubuntu's server documentation says automatic security updates are enabled by default after installation and run once per day. Ubuntu

Check the service:

systemctl status unattended-upgrades

Check the configuration:

cat /etc/apt/apt.conf.d/20auto-upgrades

A normal baseline is:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

View logs:

sudo ls -lah /var/log/unattended-upgrades
sudo tail -n 100 /var/log/unattended-upgrades/unattended-upgrades.log

For production systems, decide whether automatic rebooting is acceptable. Automatic reboots reduce the time a patched kernel sits unused, but they can also cause downtime if the server is not redundant.

8. Install baseline tools

sudo apt update
sudo apt install -y \
  curl \
  wget \
  git \
  vim \
  htop \
  tmux \
  rsync \
  unzip \
  ca-certificates \
  gnupg \
  lsb-release \
  software-properties-common

For storage work:

sudo apt install -y \
  lvm2 \
  parted \
  xfsprogs \
  e2fsprogs

For non-Plesk servers, Fail2Ban is a useful baseline protection layer:

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

For Plesk servers, prefer Plesk-managed security tools and extensions when available so panel configuration, logs, and service-specific jails stay consistent.

9. Set the default editor

Set vim as the default editor:

cat >> ~/.bashrc <<'EOF'
export VISUAL=vim
export EDITOR="$VISUAL"
EOF

source ~/.bashrc

Set Git's editor:

git config --global core.editor "vim"

10. Configure Git identity

git config --global user.name "Anthony Kung"
git config --global user.email "hi@anth.dev"
git config --global init.defaultBranch main
git config --global pull.rebase false
git config --global core.editor "vim"
git config --global color.ui auto

Check the result:

git config --global --list

11. Configure GitHub authentication

Do not cache a GitHub account password. GitHub stopped accepting account passwords for authenticated Git operations on August 13, 2021; authenticated Git operations require token-based authentication, SSH keys, OAuth, or GitHub App installation tokens. The GitHub Blog

For personal development, SSH is usually the cleanest option:

ssh-keygen -t ed25519 -C "hi@anth.dev"
cat ~/.ssh/id_ed25519.pub

Add the public key to GitHub, then test access:

ssh -T git@github.com

Use SSH remotes:

git remote set-url origin git@github.com:username/repository.git

For HTTPS workflows, use a personal access token instead of a password. GitHub says personal access tokens are alternatives to passwords for GitHub API and command-line authentication, and recommends fine-grained tokens when possible. GitHub Docs

Recommended access patterns:

Avoid this old pattern:

git config --global credential.helper 'cache --timeout=315569520'

That caches credentials for about ten years and should not be used.

12. Configure commit signing

GitHub supports verified commits using GPG, SSH, or S/MIME signatures. GitHub Docs

For new setups, SSH commit signing is often simpler than GPG:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

Add the SSH public key to GitHub as a signing key, not only as an authentication key.

For GPG signing:

gpg --full-generate-key
gpg --list-secret-keys --keyid-format LONG
gpg --armor --export YOUR_KEY_ID

Configure Git:

git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true
git config --global gpg.program gpg

Add this to ~/.bashrc:

export GPG_TTY="$(tty)"

Reload:

source ~/.bashrc

Test:

echo "test" | gpg --clearsign

Do not store personal signing keys on production servers unless the server genuinely needs to create signed commits. Signing keys belong on developer machines or controlled CI/CD environments.

13. Configure GPG agent cache safely

If using GPG, avoid extremely long passphrase cache times.

Create or edit:

nano ~/.gnupg/gpg-agent.conf

Use a reasonable cache:

default-cache-ttl 28800
max-cache-ttl 86400
default-cache-ttl-ssh 28800
max-cache-ttl-ssh 86400

Restart the agent:

gpgconf --kill gpg-agent
gpgconf --launch gpg-agent

Avoid configs like this:

default-cache-ttl 345600000
max-cache-ttl 345600000

That effectively leaves the key unlocked for years.

14. Set a Git commit template

Create a global commit message template:

nano ~/.gitmessage

Example:

Short summary under 50 characters

Why:
- 

What changed:
- 

Testing:
- 

Enable it:

git config --global commit.template ~/.gitmessage

15. Use Git LFS for large files

Use Git LFS for large binary assets, generated model artifacts, media, archives, and design files. The official Git LFS flow is to install Git LFS, run git lfs install once per user account, and then use git lfs track inside each repository for the file patterns that should be managed by LFS. Git Large File Storage

Install Git LFS:

sudo apt update
sudo apt install git-lfs -y
git lfs install

Inside a repository:

cd /path/to/repository
git lfs track "*.zip"
git lfs track "*.bin"
git lfs track "*.psd"
git lfs track "*.onnx"
git lfs track "*.pt"
git add .gitattributes
git commit -m "Configure Git LFS"

Do not use this as a default large-file strategy:

git config --global http.postbuffer 524288000

That was a common old workaround, but it does not solve the real issue of storing large binary files in Git history.

16. Inspect storage before changing LVM

Before touching LVM, inspect the current storage layout:

lsblk -f
df -h
sudo pvs
sudo vgs
sudo lvs

Check block device identifiers:

sudo blkid

Check mounted filesystems:

findmnt

17. Create a new LVM logical volume

Example: create a 100 GB logical volume called data in a volume group called vg0.

sudo lvcreate -n data -L 100G vg0
sudo mkfs.ext4 -L data /dev/vg0/data
sudo mkdir -p /data
sudo mount /dev/vg0/data /data

Verify:

df -h
lsblk -f

18. Configure automatic mounting with UUIDs

Use UUIDs or filesystem labels in /etc/fstab instead of unstable device names.

Find the UUID:

sudo blkid /dev/vg0/data

Edit /etc/fstab:

sudo nano /etc/fstab

Example:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /data  ext4  defaults,noatime  0  2

Test before rebooting:

sudo findmnt --verify
sudo mount -a
findmnt /data

19. Add a new disk to LVM

Identify the disk carefully:

lsblk

Create a GPT partition table and LVM partition:

sudo parted /dev/sdb

Inside parted:

mklabel gpt
mkpart primary 0% 100%
set 1 lvm on
quit

Create the physical volume:

sudo pvcreate /dev/sdb1

Extend the existing volume group:

sudo vgextend vg0 /dev/sdb1

Use the free space:

sudo lvextend -r -l +100%FREE /dev/vg0/data

Verify:

df -h
sudo pvs
sudo vgs
sudo lvs

20. Extend a logical volume

To add 50 GB:

sudo lvextend -r -L +50G /dev/vg0/data

To use all free space:

sudo lvextend -r -l +100%FREE /dev/vg0/data

The -r option resizes the filesystem along with the logical volume.

21. Reduce a logical volume

Reducing a logical volume is dangerous. The lvreduce manual warns that data in the reduced area is lost and that the filesystem must be resized so the removed space is not in use. man7.org

Before reducing:

sudo lvs
df -h

Back up the data first.

For ext4:

sudo umount /dev/vg0/data
sudo e2fsck -f /dev/vg0/data
sudo resize2fs /dev/vg0/data 80G
sudo lvreduce -L 80G /dev/vg0/data
sudo e2fsck -f /dev/vg0/data
sudo mount /dev/vg0/data /data

A combined command may also be used:

sudo lvreduce --resizefs -L 80G /dev/vg0/data

Still back up first.

Do not shrink XFS filesystems. XFS can grow, but it cannot be shrunk in place.

22. Migrate data between volumes

Use rsync, not cp -rp, for serious server migration:

sudo mkdir -p /mnt/oldLV /mnt/newLV
sudo mount /dev/oldvg/oldlv /mnt/oldLV
sudo mount /dev/newvg/newlv /mnt/newLV

Copy data:

sudo rsync -aAXH --numeric-ids --info=progress2 /mnt/oldLV/ /mnt/newLV/

Unmount:

sudo umount /mnt/oldLV
sudo umount /mnt/newLV

For live application data, databases, mailboxes, or Plesk hosting directories, stop the related services before the final sync.

23. Remove a logical volume

Confirm what you are removing:

sudo lvs
findmnt

Unmount it:

sudo umount /dev/vg0/data

Remove it:

sudo lvremove /dev/vg0/data

This is destructive. Confirm backups before running it.

24. Plesk on Ubuntu 24.04

Plesk Obsidian supports Ubuntu 24.04 starting from Plesk Obsidian 18.0.61, and Plesk's system requirements list Ubuntu 24.04 as the recommended Linux OS. Plesk

Known Ubuntu 24.04 Plesk limitations include PHP 7.3 and older not being shipped because those handlers are end-of-life, and the Watchdog component not being available. Plesk

Before installing or migrating Plesk to Ubuntu 24.04, verify:

lsb_release -a
hostname -f

Make sure the hostname is a real FQDN, such as:

server.example.com

A clean Plesk server should generally start from a clean OS install. Avoid installing Plesk on a server that already has manually configured web, mail, DNS, or database services unless you are intentionally handling conflicts.

25. Update Plesk

Before major Plesk updates, take a provider snapshot or full server backup.

Update installed Plesk components:

sudo plesk installer --select-release-latest --upgrade-installed-components

If the update is locked:

BUSY: Update operation was locked by another update process.

Stop the existing installer process:

sudo plesk installer stop

Then retry:

sudo plesk installer --select-release-latest --upgrade-installed-components

If package management is broken:

sudo dpkg --configure -a
sudo apt -f install
sudo apt update

Run a dry repair check:

sudo plesk repair all -n

Use non-dry-run repair only after reviewing what it plans to fix.

26. System updates on Plesk

Plesk provides a System Updates tool for Linux that uses the operating system's native package manager, such as apt, while giving administrators a UI to monitor and install updates. Plesk Documentation

CLI package updates still work:

sudo apt update
sudo apt full-upgrade

But on Plesk servers, be careful with major package changes, third-party repositories, PHP handlers, database upgrades, and mail stack changes. Plesk-managed services should be updated through Plesk-supported workflows when available.

27. Node.js on Plesk

Do not install old Ubuntu 18.04-era Node.js dependencies like this on Ubuntu 24.04 Plesk servers:

sudo apt-get install libssl1.0-dev
sudo apt-get install nodejs-dev
sudo apt-get install node-gyp
sudo apt-get install npm

For Plesk-managed hosting, use Plesk's Node.js support. Plesk documentation says Node.js support must be enabled before Node.js applications can be hosted, and website owners can configure Node.js apps from Websites & Domains -> Node.js. Plesk Documentation

Check the Plesk Node.js extension tools:

plesk ext nodejs --help

For a Node.js app, configure the runtime through Plesk so the selected Node version, document root, app root, startup file, environment variables, and logs are managed consistently.

For non-Plesk servers, install Node.js through a supported method such as the Ubuntu package repository, NodeSource, Volta, or nvm for development users. Do not mix Plesk-managed runtime paths with unmanaged system installs unless you know exactly which runtime the app is using.

28. MariaDB upgrades on Plesk

Do not blindly follow generic MariaDB upgrade guides on Plesk servers. Plesk has its own supported database upgrade workflow, and hosted websites plus Plesk itself may depend on the database service.

Plesk's MariaDB upgrade documentation strongly recommends backing up the server and starting the upgrade during off-peak hours; it also warns that Plesk and hosted websites will be unavailable during the upgrade. Plesk Documentation

Before upgrading:

sudo plesk db dump psa > ~/psa-backup.sql
sudo mysqldump --all-databases --single-transaction --routines --events > ~/all-databases-backup.sql

Also take a full server snapshot through the hosting provider when available.

Use the Plesk-supported upgrade path for the installed Plesk version, Ubuntu version, and MariaDB version.

29. Acronis Backup Agent installation

Use the installer from the Acronis management console or backup provider portal.

If the installer is a shell script:

chmod +x ./installer.sh
sudo ./installer.sh

If the installer is a binary:

chmod +x ./Cyber_Protection_Agent_for_Linux_x86_64.bin
sudo ./Cyber_Protection_Agent_for_Linux_x86_64.bin

If prompted, provide the registration token from the Acronis console.

After installation, check for Acronis services:

systemctl list-units | grep -i acronis

Then confirm that the server appears in the Acronis console and run a test backup.

30. Uninstall Acronis Backup Agent

Use the official uninstaller where available:

sudo /usr/lib/Acronis/BackupAndRecovery/uninstall/uninstall

If full removal is supported:

sudo /usr/lib/Acronis/BackupAndRecovery/uninstall/uninstall -a

If the uninstaller fails or is missing, follow Acronis's manual Linux cleanup documentation rather than randomly deleting Acronis directories. Acronis Support

31. Backup strategy

A server is not properly initialized until backups are configured and tested.

Minimum backup expectations:

A backup that has never been restored is only a guess.

For Plesk servers, backup planning should include:

/etc
/var/www/vhosts
/var/lib/mysql or database dumps
/root
/home
/usr/local/psa
/opt/psa

Exact paths depend on the server layout, enabled services, Plesk version, and backup tooling.

32. Final verification checklist

System:

hostnamectl
lsb_release -a
timedatectl
uptime

Updates:

sudo apt update
sudo apt list --upgradable
systemctl status unattended-upgrades

SSH:

sudo sshd -t
sudo systemctl status ssh

Firewall:

sudo ufw status verbose

Storage:

lsblk -f
df -h
sudo pvs
sudo vgs
sudo lvs
findmnt

Git:

git --version
git config --global --list

Commit signing:

git config --global gpg.format
git config --global user.signingkey
git config --global commit.gpgsign

Plesk:

plesk version
sudo plesk repair all -n

Acronis:

systemctl list-units | grep -i acronis

33. Operational notes

Use Ubuntu 24.04 LTS for this guide.

Use a normal sudo user instead of root for daily work.

Confirm SSH key login before disabling password login or root login.

Use SSH keys, deploy keys, GitHub Apps, or fine-grained personal access tokens for GitHub authentication.

Do not cache GitHub credentials for years.

Use SSH or GPG commit signing on developer machines or CI/CD systems. Avoid storing personal signing keys on production servers.

Use Git LFS for large binary assets.

Use UUIDs in /etc/fstab.

Use rsync -aAXH --numeric-ids for server data migration.

Treat LVM shrinking as dangerous. Extending is usually simple; shrinking can destroy data.

Use Plesk-supported workflows for Plesk updates, Node.js, MariaDB, mail, DNS, and security integrations.

Test backups before you need them.