diff --git a/docs/lessons/01_where_to_start/1.11_where_to_host.md b/docs/lessons/01_where_to_start/1.11_where_to_host.md index 462fc64..1b5a64c 100644 --- a/docs/lessons/01_where_to_start/1.11_where_to_host.md +++ b/docs/lessons/01_where_to_start/1.11_where_to_host.md @@ -1,57 +1,120 @@ # 1.11 Where to Host - +Choosing where to run Linux is an operational decision, not just a +preference. The right environment depends on what you need to learn, what +failure modes you can tolerate, how much you can spend, and who will be +responsible for patching, backups, access, and recovery. !!! abstract "What you will learn" - - Explain where **1.11 Where to Host** fits in day-to-day Linux operations. - - Use current Linux tooling to inspect, change, and verify the relevant system behavior. - - Connect the concept to a real operational scenario: a first-week junior admin onboarding into a small cloud team. + - Compare local installs, virtual machines, containers, cloud instances, and dedicated servers. + - Choose a hosting option that matches the lesson goal and risk level. + - Collect basic evidence about a Linux environment before changing it. + - Avoid common cost, security, and cleanup mistakes in learning labs. !!! example "Field story" - Imagine a first-week junior admin onboarding into a small cloud team. Your job is not to memorize a command; it is to build a short evidence trail, choose a low-risk change, and prove whether the system improved. + A junior admin wants to practice package upgrades, firewall rules, and SSH + access. A production server would be too risky, and a local container would + hide too much of the boot and networking stack. A small disposable VM or + short-lived cloud instance gives them realistic practice with a clear + rollback and cleanup plan. !!! success "Operator principle" - Identify the OS, distribution, support window, and package source before changing anything. - -## Hands-on practice + Pick the smallest environment that teaches the skill without putting real + data, real users, or uncontrolled costs at risk. -Run these on a disposable VM, container, or lab machine unless the lesson explicitly says otherwise. - -1. Inspect the current state with a read-only command related to this topic. -2. Save the command and output in a short lab note. -3. Make one reversible change or simulate the change in a sandbox. -4. Re-run the inspection and explain what changed. - -## Check your understanding +## Common hosting choices -- What evidence would tell you that this system is healthy? -- What is the riskiest command in this lesson, and how would you make it safer? -- How would you explain section 1.11 to a teammate during an incident handoff? +Use the hosting option that matches the kind of Linux behavior you need to +observe. +| Option | Best for | Watch out for | +| --- | --- | --- | +| Local dual boot or spare machine | Hardware, installation, disk layout, firmware, and desktop Linux practice | Partitioning mistakes, missing backups, and hardware-specific driver problems | +| Local virtual machine | General administration, package management, services, networking, and rollback practice | VM resource limits and networking modes that differ from production | +| Container | Command-line practice, packaging experiments, and quick disposable tests | Containers do not behave like full hosts: no normal boot flow, kernel ownership, or full init system by default | +| Cloud virtual machine | SSH, firewalls, DNS, public networking, cloud images, and remote administration | Billing, exposed services, weak keys, forgotten disks, and provider-specific defaults | +| Dedicated or rented server | Bare-metal performance, storage, hosting, and long-running services | Higher cost, slower recovery, provider support boundaries, and greater security responsibility | -Depending on your goals, how deep you want to dive, and your economic capabilities, there are multiple places where you can host Linux. +## Start with a disposable lab -**Local Machine**: If you have a powerful enough computer, you can create a partition and install Linux directly onto it. This gives you an authentic experience and the complete ability to control your environment. 🛠️💻 +For most early lessons, a local VM is the safest default. It is close enough to +a real server to practice services, logs, package managers, users, and network +configuration, but it can be snapshotted and rebuilt quickly. -**Virtual Machine**: If you don't want to affect your system or you are using an OS like Windows or macOS, you could set up a Virtual Machine (VM). Tools like VirtualBox allow you to emulate a Linux environment within your current OS, providing a safe sandbox to test and learn. 🔮💼 +Before making changes, capture a short baseline: ```bash -# Download and install VirtualBox -sudo apt install virtualbox +hostnamectl +cat /etc/os-release +uname -a +ip addr show +df -h ``` -**Cloud Instances**: For a hands-on approach and the chance to simulate real-world experience, cloud platforms like AWS, Google Cloud, or Azure can be used to create Linux instances. This way, you can learn and apply your knowledge in a practical cloud environment. Be aware; this option could incur costs. ☁️💲 +Record where the system runs, how it was created, and how you will recover it: -```bash -# Create an EC2 instance on AWS -aws ec2 run-instances --image-id ami-0abcdef1234567890 --count 1 --instance-type t2.micro +```text +Environment: local VM in VirtualBox +Distribution: Ubuntu 24.04 LTS +Network mode: NAT +Snapshot: before-package-upgrade-2026-05-14 +Rollback plan: revert to snapshot if SSH or package management breaks +Cleanup plan: delete VM after the lab ``` -**Dedicated Server**: If you need a dedicated Linux environment accessible from anywhere, you could rent a server from a provider like DigitalOcean or Linode. This option not only gives you the full experience but also exposes you to network management and remote system administration.🌐🏢 +## Cloud labs need guardrails -```bash -# Connect to your remote server -ssh username@your_server_ip -``` +Cloud instances are excellent for practicing SSH, public networking, DNS, and +remote administration. They also make it easy to spend money or expose a weak +service to the Internet. + +Use these checks before creating a cloud lab: + +1. Set a budget alert or spending limit if the provider supports it. +2. Use the smallest instance type that can run the lesson. +3. Allow SSH only from your current IP address when possible. +4. Use SSH keys, not password login. +5. Name temporary resources with an expiration date. +6. Delete unused instances, volumes, snapshots, IP addresses, and load balancers when the lab is done. + +After a cloud lab, verify cleanup from the provider console or CLI. A stopped +VM may still have billable disks, snapshots, or static addresses. + +## Match the environment to the lesson + +Use a full VM or server when the lesson involves boot behavior, systemd, +kernel modules, real network interfaces, storage layout, firewalls, SSH, or +multi-user administration. + +Use a container when the lesson is about shell commands, package inspection, +file layout, basic scripting, or disposable experiments that do not need a +complete host. + +Use a cloud instance when the lesson needs public Internet routing, DNS +records, provider firewalls, remote SSH, or practice with infrastructure you +can reach from anywhere. + +Avoid practicing destructive storage, firewall, bootloader, or account-lockout +changes on any host you cannot rebuild or access through an out-of-band +console. + +## Hands-on practice + +Run these steps on a disposable VM, container, or cloud instance. + +1. Choose one environment for a Chapter 01 lab and write down why it is the + right risk level. +2. Capture the baseline commands above. +3. Identify the rollback path: snapshot, rebuild command, backup, rescue + console, or deletion and recreation. +4. If the lab is in the cloud, identify every billable resource attached to it. +5. Destroy or revert the lab when finished, then verify that no unwanted + resources remain. + +## Check your understanding -Remember to consider factors like cost, learning objectives, and system requirements which will help you determine the best hosting solution for your Linux journey. Happy exploring!🎈🎉 +- Why is a local VM often a better first lab than a public cloud server? +- What Linux topics are poorly represented by a container? +- What evidence would you collect before changing a remotely hosted server? +- What resources can keep costing money after a cloud VM is stopped? +- How would you make a firewall or SSH lesson recoverable before starting it?