Linux Server Installation and Configuration: Complete Guide and Best Practices

A properly installed Linux server is only the beginning. A production-ready system also needs a predictable storage layout, secure remote access, controlled privileges, reliable updates, logging, backups, monitoring and a configuration that another administrator can understand months later.

This guide walks through the installation and initial configuration of a Linux server using practical examples that apply to common server distributions such as Ubuntu Server, Debian, AlmaLinux and Rocky Linux.

The goal is not simply to get a login prompt. The goal is to build a server that is maintainable, secure and ready to host real workloads.

Choosing a Linux server distribution

There is no single distribution that is correct for every server. The choice depends on operational requirements, support lifecycle, application compatibility and the experience of the administrators maintaining the system.

Distribution	Typical use	Main advantage
Ubuntu Server LTS	Cloud, VPS, general server workloads	Long support cycle and large ecosystem
Debian	Stable infrastructure and self-hosting	Conservative and predictable
AlmaLinux	Enterprise-style environments	RHEL-compatible ecosystem
Rocky Linux	Enterprise and hosting workloads	RHEL-compatible ecosystem

For a new server where no application imposes a specific requirement, an Ubuntu LTS or Debian installation is often a very practical starting point. AlmaLinux and Rocky Linux are excellent choices when compatibility with the Red Hat ecosystem is important.

Before installation: document the server

Before booting the installer, write down the basic design. This prevents improvised decisions during installation.

• hostname;
• management IP address;
• subnet and gateway;
• DNS servers;
• storage layout;
• filesystem;
• administrator account;
• SSH access method;
• backup destination;
• services the server will provide.

A simple server sheet can save a surprising amount of time during troubleshooting and disaster recovery.

Verify the installation image

Download the ISO image from the official distribution website and verify its checksum before using it.

sha256sum linux-server.iso

Compare the result with the SHA-256 value published by the distribution vendor.

This protects against corrupted downloads and helps confirm that the image you are installing is the expected one.

Minimal installation is usually better

For a server, start with the smallest practical installation.

Do not install a graphical desktop unless the workload genuinely requires it. Every unnecessary package increases disk usage, update complexity and potentially the attack surface.

A typical headless server needs little more than:

• the base operating system;
• SSH server;
• network utilities;
• time synchronization;
• basic administration tools.

Storage layout

Storage design should reflect the role of the server. A small VPS and a database server should not necessarily use the same partition layout.

A simple installation might use:

/boot
/
swap

More complex systems may separate:

/
/var
/var/log
/home
/srv
/tmp

Separate filesystems can limit the impact of an application filling a filesystem, but they also require more capacity planning. There is no value in creating many partitions without a clear operational reason.

ext4, XFS or Btrfs?

For most general-purpose servers, ext4 remains a simple and reliable choice.

XFS is widely used on enterprise Linux systems and performs well for large filesystems and many server workloads.

Btrfs offers advanced features such as snapshots and checksumming, but operational experience with the filesystem is important before choosing it for critical workloads.

LVM

Logical Volume Manager is useful when storage requirements may change over time.

pvs
vgs
lvs

LVM allows logical volumes to be extended and storage devices to be managed more flexibly than fixed partitions.

First boot: update immediately

After the first login, update the operating system before deploying applications.

Ubuntu / Debian

apt update
apt full-upgrade

AlmaLinux / Rocky Linux

dnf update

If the kernel or critical system components were upgraded, reboot before continuing.

reboot

Verify the system after reboot

uname -a
cat /etc/os-release
uptime
systemctl --failed

The last command is especially useful. A newly installed server should not begin its life with failed systemd units that nobody investigates.

Configure the hostname

hostnamectl

To change it:

hostnamectl set-hostname server01.example.internal

Verify:

hostname
hostname -f

A consistent hostname scheme becomes increasingly important once the environment grows beyond a few servers.

Create an administrative user

Routine administration should not be performed directly as root.

Ubuntu / Debian

adduser adminuser
usermod -aG sudo adminuser

AlmaLinux / Rocky Linux

useradd -m adminuser
passwd adminuser
usermod -aG wheel adminuser

Test sudo before closing the root session

Open another terminal and verify that the new account can elevate privileges.

su - adminuser
sudo whoami

The expected result is:

root

Never disable a working administrative path before confirming that the replacement actually works.

Configure SSH keys

Public-key authentication is preferable to password-only SSH access.

On the administrator workstation:

ssh-keygen -t ed25519

Copy the public key:

ssh-copy-id adminuser@server-ip

Then test a new session before modifying sshd configuration.

Harden SSH

OpenSSH settings are commonly found in:

/etc/ssh/sshd_config

or in configuration snippets below:

/etc/ssh/sshd_config.d/

Typical hardening options include:

PermitRootLogin no
PubkeyAuthentication yes

Password authentication can also be disabled, but only after verifying key-based access:

PasswordAuthentication no

Validate the configuration before restarting or reloading SSH:

sshd -t

If the command prints nothing, the syntax is valid.

Do not rely on changing the SSH port

Moving SSH from port 22 may reduce low-effort automated log noise, but it is not a replacement for authentication controls, firewalling and patching.

Security should come from strong authentication and restricted access, not from assuming that an attacker cannot discover another TCP port.

Configure a firewall

A newly installed server should expose only the services that are actually required.

Ubuntu with UFW

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable
ufw status verbose

AlmaLinux / Rocky Linux with firewalld

systemctl enable --now firewalld

firewall-cmd --permanent \
  --add-service=ssh

firewall-cmd --reload

firewall-cmd --list-all

Restrict management access where possible

If administrators connect from known networks, SSH does not need to be exposed to the entire Internet.

Allowing management access only from a VPN, management VLAN or trusted IP range substantially reduces unnecessary exposure.

SELinux and AppArmor

Mandatory access control should not be disabled simply because an application initially fails to start.

Ubuntu commonly uses AppArmor, while AlmaLinux and Rocky Linux use SELinux.

Check SELinux

getenforce
sestatus

A production server should normally remain in enforcing mode unless there is a documented operational reason not to.

Time synchronization

Accurate time is essential for logs, TLS certificates, distributed applications, authentication and incident investigation.

timedatectl

Check synchronization:

timedatectl timesync-status

In enterprise environments, point systems to the organization’s authoritative NTP infrastructure.

DNS configuration

A server that cannot reliably resolve DNS will eventually produce confusing application failures.

resolvectl status

getent hosts example.com

Do not test DNS only with ping. Use tools that exercise the system resolver path used by applications.

Check listening services

ss -lntup

Every listening port should have an explanation.

If you do not know why a service is listening, investigate before putting the server into production.

Disable unnecessary services

systemctl list-unit-files \
  --type=service \
  --state=enabled

To disable a service that is genuinely unnecessary:

systemctl disable --now SERVICE

Do not disable unfamiliar services blindly. Determine what they do and whether other components depend on them first.

Swap configuration

swapon --show
free -h

Whether swap is required and how much depends on the workload. Database servers, container hosts and small VPS systems may need very different memory strategies.

Swap is not a replacement for sufficient RAM, but having no swap at all can also be a poor choice for some workloads.

Filesystem capacity and inode usage

df -h
df -i

A filesystem can fail because it runs out of blocks or because it runs out of inodes. Monitoring should cover both.

Log management

On systemd-based distributions, journalctl is one of the most important diagnostic tools.

journalctl -p warning -b

For a specific service:

journalctl -u ssh
journalctl -u nginx

Depending on the distribution and application, traditional logs under /var/log are also important.

Log rotation

Verify that application logs cannot grow indefinitely.

ls -l /etc/logrotate.d/

Applications that bypass journald often require an explicit logrotate policy.

Automatic security updates

Security updates should have a defined process. On small systems it can make sense to automate at least security-related packages.

On Debian and Ubuntu, unattended-upgrades can be used where appropriate.

apt install unattended-upgrades

For critical production systems, automatic patching should still be combined with monitoring, maintenance planning and a tested recovery strategy.

File permissions

Avoid permissive fixes such as:

chmod -R 777 /application

This usually hides the actual ownership or application design problem and creates unnecessary security exposure.

Inspect ownership and permissions explicitly:

ls -la
stat FILE
namei -l /path/to/file

Use least privilege

Applications should run under dedicated service accounts whenever practical.

A web application should not need unrestricted root access simply because configuring the correct permissions takes more effort.

Backup before production

Do not wait for the first incident before deciding how the server will be backed up.

A backup strategy should answer four questions:

• What is backed up?
• Where is the backup stored?
• How long is it retained?
• How is restore tested?

A backup that has never been restored is only an assumption.

What should be backed up?

At minimum, consider:

/etc
/home
/root
/srv
/opt
application data
database dumps
encryption keys
deployment configuration

The exact list depends on the workload. A rebuildable operating system may be less important than the application data and configuration stored on it.

Never store the only backup on the same server

A local backup is useful for quick recovery, but it is not sufficient by itself.

If the server suffers storage failure, compromise or physical loss, a backup stored only on that same server may be lost with it.

Monitoring

A server should be monitored before it becomes important, not after the first outage.

At minimum monitor:

• CPU usage;
• load average;
• memory;
• filesystem space;
• inode usage;
• disk health;
• network reachability;
• critical services;
• backup jobs;
• certificate expiration.

Useful diagnostic commands

uptime
free -h
df -h
df -i
lsblk
ip -br addr
ip route
ss -lntup
systemctl --failed
journalctl -p warning -b

Check disk health

For physical disks where SMART is available:

smartctl -a /dev/sda

Install smartmontools if required by the distribution.

Configuration management

As infrastructure grows, manual configuration becomes difficult to reproduce consistently.

Tools such as Ansible can document and automate server configuration:

inventory
playbooks
roles
templates
variables

Even a small environment benefits from repeatable configuration instead of undocumented shell history.

Do not install everything directly on the host

A server is easier to maintain when its role is clear.

Avoid turning one machine into an undocumented combination of database server, reverse proxy, monitoring platform, VPN gateway, CI runner and unrelated experiments unless that design is deliberate.

Virtualization, containers and separate hosts can provide useful isolation where appropriate.

Document changes

Record important changes such as:

• network changes;
• firewall rules;
• installed services;
• storage modifications;
• administrator accounts;
• scheduled jobs;
• backup configuration;
• application dependencies.

Good documentation reduces dependence on memory and makes recovery faster.

Production readiness checklist

1. Installation media verified.
2. Minimal operating system installed.
3. System fully updated.
4. Hostname configured.
5. Static network configuration verified.
6. DNS resolution tested.
7. Time synchronization working.
8. Administrative user created.
9. SSH keys tested.
10. Direct root SSH login disabled where appropriate.
11. Firewall enabled.
12. Only required ports exposed.
13. SELinux/AppArmor kept active.
14. Unused services reviewed.
15. Filesystem usage checked.
16. Logging and rotation verified.
17. Backup configured.
18. Restore procedure tested.
19. Monitoring enabled.
20. Documentation completed.

Final thoughts

A Linux server installation is easy to complete. Building a server that remains understandable, secure and recoverable after months or years is the more important task.

Start with a minimal operating system, expose only the services you need, use strong administrative access, keep mandatory access controls enabled, patch regularly, monitor the machine and test your backups.

Most serious operational problems are not caused by the Linux installer. They are caused by undocumented changes, excessive privileges, missing backups and services that nobody remembered to monitor.

A good server is not simply one that works today. It is one that can be understood, maintained and recovered tomorrow.