Chapter 1: Build Your Practice Lab

What you are building

The guide's exercises assume a conventional Ansible training classroom: a workstation control node and managed hosts servera to serverd on lab.example.com. This chapter builds a faithful copy on one Ubuntu machine at home, with Rocky Linux 9 VMs using the usual classroom names, IP addresses and users, on a private network that nothing outside can connect into.

• Understand the lab's layout, addresses and accounts before you build anything.
• See exactly which traffic the sealed network allows and blocks.
• Check that your machine meets the requirements, and fill in your own lab values.

The site's system administration path uses a lighter version of this lab: workstation, servera and serverb, without Ansible. This lab is a complete superset of it, with the same names, addresses, lab command and rht-vmctl, so if you build this one you never need the other.

It can't be grown into this one in place: its machines were built without the devops account Ansible connects as, and cloud-init only sets that up when a machine is first created. Keep anything you want from its workstation, tear it down, then build this lab from section 1.3 onwards. Your host preparation, the seal's rules file and rht-vmctl stay as they are.

The idea in one picture

Six VMs sit on a private network called rhcebr0. Inside that network they talk to each other freely, and they can reach the internet, so dnf install works. From outside, nobody can open a connection in: not your laptop, not your router, and not even the host itself. You step inside with lxc exec (which does not use the network at all), then SSH between the VMs exactly as in the classroom.

Pick a traffic flow to see its path and the firewall rule that decides it:

• VM ↔ VM inside the lab (SSH, ping, HTTP, anything)
• VMs → internet (package installs, downloads)
• You → a VM through lxc exec or the LXD UI's Terminal tab
• VMs → the lab's own DHCP and DNS service

• Any device on your local network → the lab
• The host itself → the lab (no ssh, no ping)
• The lab → your local network and any private or VPN ranges
• The lab → any service on the host other than DHCP/DNS

The address plan

The lab uses the classroom network 172.25.250.0/24 and the domain lab.example.com, so every hostname and IP address in this guide works unchanged.

Accounts on every VM

Where each step happens

Every step in this chapter is labelled with where you run it:

A terminal on the Ubuntu host.

The LXD web interface in your browser.

Inside a lab VM, usually as student on workstation.

Your lab values

A few values differ on every home network. The instructions write them as placeholders, highlighted in amber: <HOST_LAN_IP>, <HOST_USER> and <ROUTER_IP>. Enter yours once here and every command in this guide shows (and copies) your real values instead:

Everything else, including the 172.25.250.0/24 network, the hostnames and the student/devops passwords, is the same for everyone.

Why the host has two IP addresses

Your Ubuntu host keeps its normal address on your local network, <HOST_LAN_IP>. When you create the lab network, LXD builds a virtual switch called rhcebr0 inside the host and gives the host a second address on it: 172.25.250.254. That second address is the lab's gateway.

Why the host has two IP addresses: The host keeps its normal LAN address (wired or Wi-Fi) and gains a second one, 172.25.250.254, on the lab's virtual switch. The VMs use that second address as their gateway.

The gateway can't be removed: without it the VMs would get no addresses (DHCP), couldn't find each other by name (DNS), and couldn't install packages. What you can do, and what the seal does, is make it one-way: traffic may leave the lab, but nothing, including the host, may start a connection into it.

What you need

With all six VMs running idle, the tested host measured:

Tested versions

Newer patch releases should behave the same. If something differs, compare against this table first.

The build at a glance