How To Install Ubuntu Server

How to Seamlessly Install Ubuntu Server for Optimal Performance and Security

Server deployment failures often originate from cutting corners during installation. The initial setup phase defines how your Ubuntu Server will perform, how reliably it scales, and how effectively it resists intrusion over its entire lifecycle.

Foundation First: Why Server Installation Choices Matter

Operating systems aren’t all equal the moment you boot them up—especially in production. Default Ubuntu Server installs frequently expose unnecessary services, rely on generic partition layouts, and skip over hardware-specific optimizations. To avoid avoidable downtime or performance headaches a few months in, invest time up front.

Stepwise Installation for Robust, Secure Ubuntu Servers

1. Selecting Ubuntu Server Version

Production setups demand stability and predictable update cycles. Unless you are targeting experimental workloads, deploy the latest Long Term Support (LTS) release—as of this writing, Ubuntu Server 22.04 LTS (jammy) is standard. LTS gets five years of security updates and extensive community support.

Known Issue: If you're running platforms with bleeding-edge kernel dependencies (e.g., some new AMD EPYC servers), cross-check kernel version support before committing.

2. Create Reliable Installation Media

Never use unverified builds—download .iso images directly from ubuntu.com/download/server. Validate the SHA256 checksum:

sha256sum ubuntu-22.04.4-live-server-amd64.iso
# Compare with published value on the Ubuntu downloads page

Create bootable USB media with BalenaEtcher (cross-platform), Rufus (Windows), or plain dd for Unix-like systems:

sudo dd if=ubuntu-22.04.4-live-server-amd64.iso of=/dev/sdX bs=4M status=progress
sync

Replace /dev/sdX with your target USB device. Not your machine's main disk—triple-check!

3. Disk Partitioning: Separate Concerns, Isolate Risk

Automated layouts (“Use entire disk”) are fine for disposable VMs. Not for production hardware or cloud VMs with multiple workloads.

Recommended approach:

• /boot (500MB, ext4)
• swap (size depends: generally 1x RAM; skip if using ZFS with swapfile)
• /var (at least 10GB; logs, package cache, databases)
• /home (remaining space)
• / (20-30GB is usually sufficient)

Create partitions manually. Use LVM to enable resizing live volumes and snapshots. Hardware-level encryption via LUKS is non-optional on laptops or systems storing regulated data (GDPR, HIPAA).

[Disk Partition Example]
| Mount   | Size    | FS     | Notes                                  |
|---------|---------|--------|----------------------------------------|
| /boot   | 500MB   | ext4   | Kernel images, isolated boot attacks   |
| swap    | 8GB     | swap   | Adjust as per RAM                     |
| /       | 30GB    | ext4   | System                                 |
| /var    | 20GB    | ext4   | Logs/DB cache, consider xfs on heavy  |
| /home   | *rest*  | ext4   | User/application files                 |

Non-obvious tip: Place /tmp on its own partition and mount with noexec,nosuid for additional hardening.

4. Minimal Install, Minimal Attack Surface

During package selection, deselect anything not required for your stack. For most deployments, start with only the core system and OpenSSH. Layer on NGINX, PostgreSQL, etc. afterward via apt.

Unused services waste resources and expand your patch management workload.

5. Hardened User & SSH Setup

• Create a primary user: Grant admin with sudo—never log in directly as root.
• OpenSSH: Enable only if remote management is essential at install. Otherwise, keep disabled until network lockdowns (firewalls, VPN) are in place.
• Key-based authentication only—password logins are a liability.

Generate and install your SSH keypair:

ssh-keygen -t ed25519 -C "ubuntu-server-admin"
ssh-copy-id user@<server_ip>

Immediately post-install, edit /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no

Restart SSH:

sudo systemctl restart ssh

Gotcha: Lose your SSH key, and remote recovery is painful without serial or console access.

6. Static Network Configuration with Netplan

Servers shouldn’t rely on DHCP—addresses must be stable for service exposure, firewalling, monitoring, and DNS PTRs.

During install, set the primary network interface (e.g., ens160, eth0) to manual/static. If you miss it, edit /etc/netplan/01-netcfg.yaml later:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
      addresses: [10.100.10.5/24]
      gateway4: 10.100.10.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

Apply the config:

sudo netplan apply

Test network connectivity before deploying upstream services.

7. Immediate Patching and Security Updates

Fresh installs are dated installs by the time setup completes.

sudo apt update
sudo apt dist-upgrade -y
sudo reboot

After reboot, enable unattended security updates:

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

Real-world note: On baremetal servers, always check for out-of-band firmware updates (ILO, DRAC, BMC) not handled by the OS.

Summary Matrix

No installation is bulletproof, but attention to these practical details drastically reduces operational surprises later. In practice, experienced teams maintain golden images using the above strategy—further automated through PXE boot, Preseed/Cloud-init, or Terraform when scaling to fleets.

Don’t hesitate to build, then iterate. Sometimes the best lessons surface only at 3AM on a Sunday shift—prepare for them up front.