Ahosting Logo

Dedicated Server

Installing and Managing Operating Systems on Dedicated Servers

On physical hardware, the disk layout is the decision that lastsAlmost everything else· packages, services, configuration· all changeable later, at low costThe disk layout· partitioning and filesystem choices· RAID level and how the array is built· changing it later means a rebuildSo decide before installingHow much space each area needs, whether logs and mail can fill the root filesystem, and whichRAID level you can actually afford to rebuild.

Which distribution to run, and why support lifetime should decide it rather than preference, is the same question on any machine. Installing an operating system on a VPS goes into it and the answer does not change here.

What is different on physical hardware is that you are laying out real disks, and that layout is set during installation.

Two routes to an install

The provider's template. Fast, and it uses their default layout, which is usually a single large partition covering everything.

Your own image, through the management console. Mount an installation image over the network, boot from it, and install as if you were standing in front of the machine.

The second route is slower and is the only one that gives you control of the layout. Using IPMI and out-of-band management walks through reaching the console, which is also how you recover a machine that will not boot afterwards.

Why the layout is the decision that matters

Almost everything about a server can be changed while it runs. Packages, services, users, firewall rules, even the kernel.

Partitioning cannot. Correcting it means moving the data off, reinstalling, and putting it back, which is a maintenance window and a restore instead of an edit.

So it is worth ten minutes now.

Use a volume manager

Installing onto logical volumes rather than raw partitions costs nothing and removes most of the risk of getting the sizes wrong.

Space can be moved between areas later, and an area can be grown into free space, without repartitioning. Given that nobody predicts a server's growth accurately, this is the single most useful choice on the screen.

Separate what grows

A single partition covering everything is simple and has one failure mode: anything that grows without limit fills the same space the system needs to function.

A runaway log or a database that doubled then stops the machine writing at all, and a system that cannot write its own files fails in ways that are much harder to recover from than a full data area.

Giving logs and application data their own space converts that from an outage into a contained problem. Managing logs and log rotation goes into keeping them in check either way.

Size the boot area generously

A small boot partition fills with old kernels, and when it is full, updates fail, with an error about disk space on a machine that has terabytes free.

It is a small allocation and it causes a disproportionate amount of confusion later. Give it more than the installer suggests.

Decide encryption now

Full-disk encryption is set at installation. Adding it afterwards means moving all the data off and back.

On physical hardware it is what protects you when a drive leaves the building. A failed disk returned to the manufacturer, or one that is replaced and disposed of. That is a real path, not a theoretical one.

The cost is a passphrase at boot, unless you arrange otherwise, which matters if the machine must come back up unattended. Server hardening best practices goes over the rest of the physical-layer questions.

The array is part of the layout

Redundancy is configured before or during installation, and it is the other choice that is expensive to revisit.

What matters at this point is knowing which arrangement you have and what a single failure means for it, setting up RAID and storage management explains it, and monitoring server health covers the fact that a failed member is silent by design.

Write down what you chose

Layout, array configuration, filesystem, encryption, and the version installed.

Two years later, when the machine needs rebuilding or a disk needs replacing, this document is the difference between a planned operation and reverse-engineering your own decisions under pressure. Managing multiple servers consistently explains keeping it somewhere it will be found.

Automate the install rather than repeating it

Building a machine by answering installer questions produces a machine nobody can reproduce.

Every distribution supports an answer file: kickstart, preseed, autoinstall: that performs the whole installation from a specification, including the partition layout.

Two benefits follow, and the second is the larger one. The build is repeatable, so a replacement machine matches the original. And the file is the documentation: the partition sizes, the filesystem choices and the packages are stated rather than remembered.

Keep it in version control alongside whatever else describes the server. Managing multiple servers consistently walks through the wider practice.

Check the layout before the machine carries anything

lsblk -f
df -h
findmnt -t ext4,xfs -o TARGET,SOURCE,FSTYPE,OPTIONS

Confirm what was actually created rather than what was requested: installers occasionally resolve conflicting choices in ways the operator did not intend, particularly around the boot partition and swap.

The mount options are worth reading too. A data partition mounted without noatime writes an access timestamp on every read, which on a busy server is measurable and is easy to change now and awkward later.

Swap deserves a deliberate choice

The default is frequently either absent or a fixed fraction of memory, and neither is right on a large modern machine.

Too little means the system starts terminating processes as soon as memory is exhausted rather than degrading. Too much on a machine with plenty of memory wastes space and can make a stall worse, because the machine swaps rather than failing quickly.

A modest swap area plus a tuned swappiness value is the usual answer on a server: enough to absorb a spike, not enough to hide a memory problem. Configuring swap and memory explains the values.

The first hour after installation

A freshly installed machine is at its most exposed, because it is reachable and not yet configured.

Before anything else: disable password authentication for SSH, create the account you will actually use, apply the outstanding updates, and enable the firewall: in that order, with a scheduled revert armed before touching the firewall.

ss -tlnp
systemctl list-units --type=service --state=running | head -20

Then read what is listening and what is running, and remove what the installation included that you did not ask for: securing your VPS goes into the sequence, and configuring a firewall without locking yourself out goes over the revert.