Theory is over. In this lesson you build the lab you will use throughout the eight modules of the course: a machine called srv-tramontana with Ubuntu Server 24.04 LTS, an operator user and a working SSH server.

This is not a formality. The way you install a server conditions everything that comes afterwards: if you do not verify the ISO, you do not know what you have installed; if you partition badly, a runaway log can bring the whole machine down; and if you do not take snapshots, every risky experiment in the course becomes Russian roulette. You are going to see the available options and when to use each one, how to verify the integrity and authenticity of the image, the Ubuntu Server installer step by step — with partitioning explained from scratch — and how to leave the machine ready and with a safety net.

Give it as much time as it needs. A well-built lab pays for itself.

1. Options for building the lab and when to use each one
2. The recommendation for this course
3. Downloading the ISO and verifying it
4. Creating the boot medium and booting from UEFI
5. The Ubuntu Server installer step by step
6. Partitioning: what it is and how to decide
7. VM snapshots: your safety net
8. First boot and first update
9. A mental snapshot of what you have created

Three clarifications that avoid frequent misunderstandings:

• WSL2 is not a substitute for a VM in this course. It is excellent for writing scripts and using tools, but it does not boot like a real server, systemd works with limitations, there is no boot process to study (Module 7) and the network is mediated by Windows. If you work on Windows, use it as a convenient complement, not as your main lab.

• A container is not a machine. It shares the host's kernel and starts a single process. You cannot practise systemd, or booting, or disk management, or real network configuration. Containers are a topic of the course, not the infrastructure of the course.

• An exposed cloud server is a real target. If you open SSH with password authentication on a public IP, you will start receiving automated access attempts within minutes. That is not an exaggeration: it is what happens. It is an excellent exercise for Module 6, but not for day one.

If your laptop is a Mac with an Apple Silicon chip, take note of this now so you do not lose an hour later: you need the Ubuntu Server ARM64 ISO, not the AMD64 one.

A virtual machine with Ubuntu Server 24.04 LTS, called srv-tramontana.

Minimum and recommended resources:

A rule that gets forgotten and causes trouble: do not give the VM more than half your machine's RAM or cores. If your laptop has 8 GB, give it 4 at most. A choked host makes everything worse, the VM included.

Optionally, a second VM with Ubuntu Desktop 24.04 LTS (user student, 4 GB of RAM, 30 GB of disk) to practise with a graphical environment. It is not essential: the whole course can be followed with the server alone, and that is in fact how you will work in real life. If you already use Linux or macOS on your machine, your own system plays that role.

It deserves a couple of lines because it determines whether you will be able to connect over SSH:

• NAT: the VM reaches the internet through your machine. It is the default mode and it is enough for installing packages. From the host you cannot connect to the VM directly unless you configure port forwarding.
• Bridged adapter: the VM appears on your local network as just another machine, with its own IP. It is the closest thing to a real server.
• Host-only network: a private network between your machine and the VM. Combined with NAT it is the most convenient configuration for a lab: internet on one side, stable SSH access on the other.

Recommended configuration: adapter 1 on NAT + adapter 2 on a host-only network. We will go deeper into it in Module 6.

An ISO is the image of an installation disc: a single file containing the installer's complete file system.

Always download it from the official site: https://ubuntu.com/download/server. For Ubuntu Server 24.04 LTS the file is called ubuntu-24.04.x-live-server-amd64.iso and takes about 2.5 GB.

You are about to grant that file total control over a machine. If it has been tampered with, everything you do afterwards is worthless: no password, firewall or antivirus will protect you from a system that was compromised at installation time.

The risks are real and documented: interrupted downloads that leave the ISO corrupt, compromised mirrors, fake download sites ranking well in search engines, man-in-the-middle attacks on public networks. Verifying takes two minutes.

You have to make two different checks, and confusing them is a common conceptual mistake:

In other words: SHA256 checks integrity; the GPG signature checks authenticity. Only by doing both do you close the circle.

The commands below are run on Linux or macOS. On Windows you can use WSL2, Git Bash or the PowerShell equivalents.

Step 1. Download the auxiliary files. They are in the same directory as the ISO, at https://releases.ubuntu.com/24.04/:

• SHA256SUMS: a text file with the hash of every published image.
• SHA256SUMS.gpg: the cryptographic signature of that file, made by Canonical.

Step 2. Check the SHA256 sum.

Expected output:

What each part does:

• sha256sum computes the file's cryptographic fingerprint: a 64-hexadecimal-digit number that changes completely if a single bit is modified.
• -c SHA256SUMS tells it to read the sums file and check every entry it finds.
• 2>/dev/null discards the error messages for the images you have not downloaded (you will see redirection in Module 3).
• The key result is OK (translated, if your system runs in another language). If it said FAILED, delete the ISO and download it again: do not use it under any circumstances.

Step 3. Import Canonical's public key.

Output:

These two keys are the ones Canonical uses to sign its images. Their identifiers are published in the official Ubuntu documentation; check them there rather than trusting this text or any blog.

Step 4. Verify the signature.

Expected output:

How to read this output, which is where people get nervous for no reason:

• Good signature from "Ubuntu CD Image Automatic Signing Key" is the line that matters. It means the SHA256SUMS file was signed with Canonical's private key and has not been modified since.
• The WARNING: This key is not certified with a trusted signature! is normal and does not indicate a problem. GPG is only reminding you that you have not explicitly declared that you trust that key within your personal web of trust. The signature is valid.
• The fingerprint (8439 38DF ... EFE2 1092) is what you must compare with the one published on the official Ubuntu website. If it matches, you have closed the circle.

What would be alarming is a BAD signature. In that case, do not continue.

Summary of the complete reasoning: the GPG signature proves that SHA256SUMS comes from Canonical; the sha256sum -c proves that the ISO matches what that file says. Chaining the two, you know your ISO is exactly the one Canonical published.

If you are using a virtual machine, skip this section: in VirtualBox or VMware it is enough to attach the ISO to the VM's virtual optical drive. This section is for installing on real hardware.

With dd on Linux:

Output:

How to read it: sda is your internal disk (476 GB) and sdb is the USB stick (14.6 GB, the RM column set to 1 = removable). Identifying the device correctly is all the safety you have.

Each part:

• umount unmounts the USB stick: dd must write to the device, not to a mounted partition.
• if= (input file): the source, the ISO.
• of= (output file): the target, the whole device /dev/sdb, not /dev/sdb1.
• bs=4M: writes in 4 MB blocks, much faster than the default value.
• status=progress: shows progress, because otherwise dd works in complete silence.
• conv=fsync: does not consider the operation finished until everything has physically been written.

A warning to take seriously: dd does not ask and does not warn. If you type of=/dev/sda by mistake, you destroy your main disk in seconds, with no confirmation and no way to undo it. Its nickname in the community is disk destroyer. Check the target twice before pressing Enter.

UEFI is the firmware that replaced the classic BIOS. To boot from the USB stick:

1. Power on and press the boot menu key during the first few seconds: F12, F2, Esc or Del, depending on the manufacturer.
2. Choose the USB entry. If it appears twice, pick the one starting with UEFI:.
3. If the USB stick does not appear, go into the firmware setup and check:
   • Secure Boot: Ubuntu is signed and works with Secure Boot enabled. Only disable it if booting fails.
   • Fast Boot: disable it, as it skips USB detection.
   • Storage mode: it must be AHCI, not RAID/Intel RST.

The Ubuntu Server installer is called Subiquity and it works in text mode, with keyboard navigation: arrows to move, Tab to jump between areas, Space to tick, Enter to confirm. There is no mouse, and you do not need one.

1. Installer language. Choose whichever you prefer. A professional tip: select English. Practically all documentation, error messages and forum answers are in English, and searching for an error message translated into another language gives far fewer results. The keyboard layout is configured separately in the next step.

2. Installer update. If it detects a newer version, it offers to update itself. Accept: it fixes known bugs.

3. Keyboard layout. Here you should pick Spanish. You can use automatic detection, which asks you to press specific keys. Check that the ñ and the symbols @, | and / come out where you expect: you will be typing plenty of them.

4. Installation type. Choose Ubuntu Server (the standard installation), not minimized. The minimised version removes useful tools and is designed for automated cloud images.

5. Network configuration. The installer detects the interface (usually enp0s3 in VirtualBox) and requests an IP address over DHCP. You will see something like:

With NAT in VirtualBox, the IP 10.0.2.15 is normal and correct. Leave it on DHCP; in Module 6 you will configure a static IP.

6. Proxy. Leave it empty unless your corporate network requires one.

7. Package mirror. The installer proposes http://es.archive.ubuntu.com/ubuntu. Accept it; it automatically checks that it responds.

8. Disk configuration. The important step. We develop it in the next section.

9. User profile. Fill it in like this, with exactly these values, because we will use them throughout the course:

Two things are worth understanding here:

• The server's name (srv-tramontana) is the hostname: you will see it in the prompt every time you log in, and it identifies the machine on the network.
• The operator user you create here is not root, but is automatically added to the sudo group, which lets it run commands with administrator privileges. Ubuntu leaves the root account without a password and disabled for direct login, by design. You will see this in lesson 01-05 and in depth in 05-02.
• While you type the password nothing is displayed, no asterisks and no dots. It is not frozen: it is normal Unix behaviour, which does not even reveal the length.

10. Ubuntu Pro. You can skip it (Skip for now). It is free for up to 5 machines and gives 10 years of support; in a lab it adds nothing.

11. OpenSSH server. Tick the Install OpenSSH server box. It is the most important step on this screen: without it you will not be able to connect to the server from your laptop and you will always have to work in the VM console, which is uncomfortable (no copy and paste, no convenient scrolling, no multiple windows). Leave the import of keys from GitHub or Launchpad unticked; SSH keys are a Module 6 topic.

12. Featured snaps. Do not select any. We will install what we need when we need it, understanding what each thing does.

13. Installation. The process takes between 5 and 20 minutes. You can follow the log on screen with View full log, which is an excellent way of getting familiar with what an installer does. When it finishes, Reboot Now appears.

14. Remove the medium. If you installed from a USB stick, take it out. In a VM, VirtualBox usually disconnects the ISO automatically; if the installer starts again, disconnect it manually from the VM settings.

This is where most people get stuck, so let us start from the beginning.

A physical disk is a continuous surface of storage. A partition is a logical division of that disk: a portion with a beginning, an end and a purpose. The disk carries a partition table describing those divisions.

There are two table formats:

Always use GPT. Unless you work with very old hardware, there is no reason for MBR.

On top of each partition a file system is created (the format that organises files and directories inside it): on Linux, usually ext4, robust and thoroughly proven. And that partition is mounted at a point in the directory tree: that is the central idea of lesson 01-06.

Swap is disk space the kernel uses when RAM runs out: it moves the least used memory pages there to free up RAM. It is also needed for hibernation.

It is far slower than RAM, so it is not a substitute: it is a safety net that stops the system from killing processes when there is a memory spike.

The old rule of "twice the RAM" comes from an era of tiny memories and makes no sense today. Ubuntu, by default, creates a swap file (/swap.img) instead of a partition: it is just as valid and much easier to resize later.

The installer offers two paths:

• Use an entire disk: it creates /boot/efi and a single large partition for /, all inside LVM if you leave the option ticked. It is correct, simple and perfectly valid for learning.
• Custom storage layout: you decide each partition yourself.

An honest recommendation: if this is your first installation, use the default scheme. Learning partitioning and learning Linux at the same time is unnecessary. You will be able to repeat the installation with manual partitioning when you reach lesson 05-04 and understand LVM.

That said, this is the scheme an administrator would build for a server like ours, and it is worth understanding the logic:

The key partition is /var, and the reason is pure operational common sense: logs grow. If /var/log/tramontana/access.log runs away because of an error loop and /var shares a partition with /, the root disk fills up. And when / fills up, the system stops working: temporary files cannot be written, services fail, and sometimes you cannot even log in to fix it. With /var on its own partition, the problem stays contained: /var fills up, the logs stop, but the system stays on its feet and you can log in to sort it out.

That is the general principle of partitioning on servers: isolate whatever grows unpredictably.

And its counterpart, which you also need to know: fixed partitions are rigid. If you size them badly, you have space to spare in one and a shortage in another. That is exactly the reason LVM exists, allowing volumes to be resized on the fly, and you will study it in lesson 05-04. That is why Ubuntu enables it by default.

A snapshot freezes the VM's complete state — disk, memory, configuration — at a point in time. You can return to it in seconds, undoing anything you did afterwards.

It is the greatest teaching advantage of working with virtual machines: it lets you break the system on purpose. And breaking it on purpose, in an environment where going back costs 10 seconds, is the fastest way to learn systems administration.

In VirtualBox: Machine → Take Snapshot. In VMware: VM → Snapshot → Take Snapshot.

Take a snapshot right now, with the installation just finished, and call it 01-clean-install. It is your point zero: you will always be able to go back to a freshly installed system without repeating the process.

A recommended snapshot plan for the course:

Two practical warnings:

• Snapshots take up space and slow the VM down if you pile up too many. Delete the old ones you no longer need. Do not keep more than four or five active.
• A snapshot is not a backup. It lives on the same physical disk as the VM: if that disk fails, everything is lost together. Real backups are lesson 05-08.

After rebooting, you will see boot messages scroll past and you will reach the login screen:

Type operator, press Enter, type the password (remember: nothing is displayed) and press Enter. The message of the day will appear and, at the end, the prompt:

That prompt is your starting point. In the next lesson we will pull it apart character by character.

The image you installed was built weeks or months ago. Security fixes have been published since. The first thing you do on any freshly installed system is update it:

What it does exactly:

• sudo runs the command with administrator privileges. The first time it will ask for your own password (the operator one, not a root one), and it will remember it for about 15 minutes.
• apt update updates nothing: it downloads the list of available packages from the repositories and checks which ones have a new version. It is the "get informed" step.
• && chains: it runs the second part only if the first finished successfully.
• apt upgrade downloads and installs the new versions. It will ask for confirmation, showing what is going to change.

Typical output from the first part:

Reading this output:

• Hit means that repository has not changed since the last query; Get means new information was downloaded.
• noble is the code name of Ubuntu 24.04 (every version has its own: jammy was 22.04, noble is 24.04).
• There are three sources: the base repository, noble-updates (general fixes) and noble-security (security fixes, the most important one).
• 23 packages can be upgraded: that is what apt upgrade is going to install.

If, after updating, a message appears saying a reboot is needed (typical when the kernel is updated), do it:

All of this is covered in depth in lesson 05-03. Here you only need the system to be up to date.

Before moving on, be clear about what now exists:

• A virtual machine with Ubuntu Server 24.04 LTS, kernel 6.8, with no graphical environment.
• A hostname: srv-tramontana.
• A user operator, a member of the sudo group, with its home directory at /home/operator.
• A root account that exists but has no password and no direct login.
• An SSH server listening on port 22, ready for connections from your laptop.
• A partitioned disk with at least /boot/efi and /, plus swap.
• A network interface with an IP from DHCP and internet access.
• An updated system with the latest security patches.
• A snapshot called 01-clean-install that you can always go back to.

What does not yet exist and you will create over the course: the tramontana group, the directories /opt/tramontana/app, /etc/tramontana/, /var/log/tramontana/, /srv/tramontana/backups and /home/operator/scripts, and of course the Tramontana Bookings application. In lesson 01-06 you will see why each piece goes exactly where it goes.

• Installing without verifying the ISO. It is the most serious mistake in this lesson, because it silently invalidates everything you do afterwards. Two minutes of checking.
• Confusing integrity with authenticity. SHA256 only proves that the file matches the published hash. If an attacker controls the page, they control both. It is the GPG signature that ties the hash to Canonical.
• Getting scared by the "this key is not certified" warning. It is normal in GPG and does not indicate a problem. What would be alarming is BAD signature.
• Getting the device wrong with dd. Run lsblk before and after plugging in the USB stick, and compare. The difference is your USB stick.
• Forgetting to tick "Install OpenSSH server". It is the most frequent omission and the one that causes the most inconvenience. If it has happened to you, fix it with sudo apt install openssh-server.
• Thinking the password is not being typed. No asterisks appear, by design. Type with confidence and press Enter.
• Installing Ubuntu Desktop thinking it is the same thing. A server carries no desktop: it eats memory, increases the attack surface and adds nothing operationally.
• Giving the VM all the host's RAM. It chokes the host system and everything gets worse, the VM included.
• Not taking snapshots. Snapshots turn mistakes into experiments. Without them, every risky exercise feels like a chore, and reluctance is the enemy of learning.
• Tip. Write your lab configuration down in a document: VM name, resources, IP, user and password, partition scheme and snapshots taken. In three weeks you will not remember it, and documenting the infrastructure is exactly what a good administrator does.
• Tip. Once the installation works, do it a second time with manual partitioning. The first one gives you a system; the second one gives you understanding.

You have downloaded ubuntu-24.04.1-live-server-amd64.iso from a link a colleague sent you over a messaging app. Describe the complete verification procedure in four steps, stating for each one which command you run, what output you expect and what exactly it proves. Then explain why the SHA256 step, on its own, would not be enough in this particular scenario.

Marta asks you to size the disk of a future 100 GB srv-tramontana-2 that will host the bookings database and keep local copies. Propose a complete partition scheme with sizes and a justification for each one, point out which is the most critical and why, and explain what drawback your proposal has compared with using LVM.

After installing, you boot the VM and these three problems occur. Diagnose each one and propose a solution:

1. The Ubuntu installer appears again instead of the installed system.
2. When you type the password at the login prompt, no character appears on screen.
3. From your laptop, ssh [email protected] answers Connection refused.

Solution to Exercise 1

Step 1 — Download the verification files from the official source.

It is essential that this comes from releases.ubuntu.com, not from wherever the ISO came from. That is the whole point of the exercise.

Step 2 — Check the SHA256 sum.

Expected output: ubuntu-24.04.1-live-server-amd64.iso: OK. It proves: integrity, that the file you have is bit for bit identical to the one described in SHA256SUMS.

Step 3 — Import Canonical's public key.

Expected output: public key "Ubuntu CD Image Automatic Signing Key" imported. It proves: nothing on its own; it prepares the next check.

Step 4 — Verify the signature of the sums file.

Expected output: Good signature from "Ubuntu CD Image Automatic Signing Key". The warning about trust is normal. It proves: authenticity, that SHA256SUMS was signed by Canonical and has not been altered.

And to finish it off, compare the displayed fingerprint with the one published in the official Ubuntu documentation.

Why SHA256 alone would not be enough here.

The scenario says the ISO arrived through an unofficial channel. If that person (or whoever passed the file to them) had modified the ISO, all they would need to do is compute the SHA256 of the modified file and send it to you along with the link. You would check the sum, it would match perfectly, and you would be verifying the altered file against the hash of the altered file. The check would be technically correct and completely useless.

A hash only guarantees integrity with respect to a reference you trust. If the reference comes from the same source as the file, it guarantees nothing. The GPG signature breaks that circle because nobody without Canonical's private key can produce a valid signature.

In practice, that is the whole point of signature cryptography: replacing trust in the channel with trust in a verifiable key.

Solution to Exercise 2

Proposed scheme for srv-tramontana-2 (100 GB, database server with local copies):

The most critical: /var.

It holds the database data and the system logs at the same time, and both grow continuously. If /var shared space with /, a runaway log or unexpected database growth would fill the root file system, and a full / means an unusable server: temporary files cannot be created, services fail when writing their state files and sometimes you cannot even log in to fix it.

By isolating it, the worst case is that PostgreSQL stops accepting writes — serious, but recoverable — with the system still up and reachable.

Second in criticality is /srv: it has been sized as the largest partition because accumulated copies grow with every run, and it has been separated precisely so that its growth affects nothing else.

Drawback compared with LVM.

This scheme is rigid. Sizes are fixed at installation time and changing them afterwards is awkward and risky: it requires stopping the service, booting from external media, resizing the file system and moving the partition boundaries. If in a year's time the database exceeds the 25 GB of /var while 30 GB sit unused in /srv, that free space cannot be used without a delicate intervention.

With LVM (Logical Volume Manager), physical partitions are grouped into a pool from which resizable logical volumes are carved. Extending /var by 20 GB would be:

Two commands, with the system running and the service working. LVM also allows volume-level snapshots, very useful before a database schema migration.

That is why, on a real production server, the professional recommendation is: /boot and /boot/efi as ordinary partitions (LVM cannot host them comfortably) and everything else on LVM. It is exactly what the Ubuntu installer does by default, and it is studied in lesson 05-04.

Solution to Exercise 3

Problem 1 — The installer boots again.

Diagnosis: the installation medium is still connected and the firmware gives it priority in the boot order. The installation probably finished fine; it is simply booting from the wrong place.

Solution:

• In a VM: shut it down, go to Settings → Storage, select the optical drive and remove the ISO (Remove Disk from Virtual Drive). Boot again.
• On physical hardware: take out the USB stick and, if the problem persists, go into the UEFI setup and put the hard disk first in the boot order.

How to tell it apart from a real installation failure: if the disk were not bootable, on removing the medium you would see a message such as "No bootable device found", not the installer.

Problem 2 — No characters appear when typing the password.

Diagnosis: it is not a problem. It is standard Unix behaviour and has been for more than fifty years. The terminal turns off character echo while credentials are entered.

Why it is done this way: not showing even asterisks avoids revealing the password's length to anyone watching the screen, a piece of information that reduces the search space of an attack. It is a deliberate decision, not a shortcoming.

What to do: type normally and press Enter. If the password is wrong, the system will say so with Login incorrect after a pause of a few seconds — that pause is also intentional, to slow down automated attempts.

Tip: if you suspect the problem is the keyboard layout (symbols not coming out where you expect), type the password in the username field, where it is visible, to check which characters your keyboard actually produces. Then delete it and log in normally.

Problem 3 — ssh [email protected] gives Connection refused.

Two very different causes have to be separated, and the message itself helps:

Cause A, the most likely in VirtualBox: the network topology. With the adapter on NAT, the IP 10.0.2.15 belongs to a private network internal to VirtualBox. It is not reachable from the host. The error occurs before reaching the server.

Two alternative solutions:

1. Add a second adapter on a host-only network (Settings → Network → Adapter 2 → Host-only Adapter). The VM will get a second IP, something like 192.168.56.x, reachable from the laptop. It is the recommended option because it keeps internet access through NAT.
2. Configure port forwarding on the NAT adapter: host port 2222 to VM port 22. You then connect with ssh -p 2222 operator@localhost.

To find out the VM's real IP, run this in its console:

Cause B: OpenSSH is not installed. If you forgot to tick the box in the installer, there is nothing listening on port 22. Check it in the VM console:

If it answers Unit ssh.service could not be found, install it:

Ubuntu enables and starts it automatically on installation.

How to tell A from B by the error message: Connection refused means something actively answered rejecting the connection (there is no service on that port). Connection timed out or No route to host mean the machine was not reached at all, which points to a network or firewall problem. Learning to read these messages saves a huge amount of time, and we will come back to it in Module 6.

You now have a lab. In this lesson you have seen:

• The options for building a Linux environment — VM, WSL2, dual boot, hardware, cloud, container — and why the virtual machine is the right one for learning.
• How to verify an ISO with sha256sum (integrity) and GPG (authenticity), and why neither check is enough on its own.
• How to create a boot medium with dd or other tools, and the precautions it demands.
• The Ubuntu Server installer step by step, with the hostname srv-tramontana, the user operator and OpenSSH installed.
• What a partition is, what role each mount point plays and why isolating /var protects the whole system from a runaway log.
• Snapshots as a safety net that turns mistakes into experiments.
• The first boot and the indispensable sudo apt update && sudo apt upgrade.

In front of you is a cursor blinking after operator@srv-tramontana:~$ and probably the feeling of not quite knowing what to do with it. That is exactly where you should be.

In the next lesson, First Contact with the System, we will pull that prompt apart character by character, you will see what a console, a terminal and a TTY really are, you will learn the anatomy of a command and the keyboard shortcuts that will save you hours, and you will carry out the initial reconnaissance of srv-tramontana: which version it runs, how much memory it has and how much disk is free. You will start, at last, to look inside the system.