All writing

Ten questions the Ubuntu Server installer asks

The installer shows ten screens and it feels like you can click through them all. None of them is trivial — get one wrong and the server is installed, but useless.

Installing Ubuntu Server takes twenty minutes, which is why nobody calls setting up a server complicated. What's complicated isn't the installation itself, but the decisions made along the way.

There are ten screens you can look back on after the install and think "I wish I'd picked the other option". I went through all of them.

1. The first username — not root

This is the most dangerous moment of the install. If you name the first user root, that user can do anything. Type one wrong command and the system can't stop you.

On Linux you create a normal user instead, and put sudo in front of the commands that need it. It looks like extra work, but it stops you from deleting something by accident.

2. Network configuration — DHCP or manual?

A server has two options: ask the network for an IP, or set the IP by hand.

There's one reason to set it by hand: if the server gets its IP from a DHCP server at boot, the IP can change. If it changes, your DNS record goes stale, you keep looking at the old address, and you say "the server won't come up". The server is up and it has an IP — you're just looking in the wrong place.

The right choice for a server: a fixed IP, set by hand, and then written into DNS as well. It only works if both move together.

3. Hostname — must match DNS exactly

The server gets a name (say, srv-xyz). That name has to be the same in two places:

  • In the server's own settings
  • On the DNS server

If they don't match, you miss the first sign and end up wrestling with a vague "my server disappeared" error from a distance. DNS changes taking time to propagate is a separate trap.

4. File system — use LVM

If you choose "use entire disk", the installer normally sets things up on LVM. That's good. LVM lets you split a disk and grow it later; its real win is snapshots: take a point-in-time image, experiment on top of it, and roll back if things break.

It's the same idea as a virtual machine disk, but far more valuable on a physical server. You're about to apply an update and want a way back? If you have a snapshot, you have one.

5. A separate /var — logs grow

Logs grow under /var/log. When a disk starts filling up, logs are usually the first thing to stop the system. Putting /var on its own partition lets logs grow for a while without taking everything else down.

On a small server this is overkill; growing it when it fills is easy. And if you split the disk with LVM, growing the partition is easy too. So it's a one-time decision.

6. Encryption — an unexpected cost

The installer asks about disk encryption (LUKS). Turn it on and the data on disk is encrypted — and the server asks for the passphrase on every boot. On a server that's started remotely, that's a serious problem: nobody's there at boot, so the server doesn't come up.

The benefit of encryption is beyond question. So is the cost. The decision comes down to the server's physical security.

7. Updates during install — usually no

There's an option to "download updates during installation". Many people tick it. On a slow or metered connection, it drags the install out for nothing.

Most of the time: no during the install, update separately afterwards. The install finishes quickly, and when you do update, you're fully in control.

8. Third-party software — not on a server

There's an option to "install third-party software" for graphics drivers and media codecs. It makes sense on a desktop. A server doesn't need it.

It's a small detail that shows the difference between a server and a personal computer: an option that's useful on one just takes up space on the other.

9. SSH — a server is useless without it

If you don't select the SSH server, you can't connect remotely once the install finishes. You can install it by hand later, but there's no reason to.

That's the first requirement of the word "server": being reachable remotely.

10. Username and password both matter

The installer offers two ways to authenticate: password only, or an SSH key. For a server, a key is the right choice — a password can be guessed, a key can't.

In practice, though: log in with the password first, then set up the key, then turn passwords off. Do it in that order and you won't lock yourself out.

Summary

The installer asks you ten questions and your answers change the server. The most expensive mistake is not knowing which question leads to which outcome — because after a wrong choice, "I got it wrong" is easy to say, while "what does this option even do?" is hard to answer.

Coming up in the next two posts: where Windows Server and Linux do the same job differently, and what to look at in the first ten minutes of a customer outage.