RudderVirt

#Working in a Module

When you open a module you land in the console, driving a real virtual machine. Almost everything that works on a normal computer works here; these are the few things worth knowing before you start. The VM is cloned directly from a "golden" snapshot, but your copy is isolated to only you.

#Treat the VM like a system you're supporting

Think of every module as a real support job: do what you're asked, and leave everything else alone. Changing things outside the scope of the briefing can cost you points even when the rubric doesn't say so explicitly.

  • Do only what the briefing asks. The briefing defines your scope. Stay focused on it.
  • Don't change passwords you weren't asked to change. This includes root and any other accounts on the machine.
  • Don't be destructive. The goal is to fix the problem without making it worse. Move things aside instead of deleting them, and favor changes you can undo.
  • Don't make the system less secure. If a firewall is on, keep it on. Don't loosen permissions or disable protections the briefing didn't ask you to touch.
  • Don't run system updates or upgrades. They can change versions, alter configs, or restart services — and they waste time you need for the actual task.
  • Don't fall back on automated scans. These modules test your technical skills, not your ability to run a scanner.

#The virtualization landscape

You get your own private virtual network — a VPC that no other student can see or touch. Every module instance is completely isolated; your server is a different machine from another student's server, and they can't reach your VMs.

Some modules run a single VM. Others ship with multiple machines wired together on the same network — a client and server pair, a small lab, or whatever the lesson needs. Those VMs all clone together when you start, all run in the background while you work, and you can see how they're wired by looking at the network addresses inside each machine.

When a module has multiple VMs, a Switch VM menu appears in the console menu bar. Click any VM in the list to jump to that machine's console. You're only driving one at a time, but the others keep running — if two machines need to talk to each other to solve the scenario, switch over, do the work, and switch back.

The briefing tells you the network layout, what each machine's role is, and what addresses they have. See Multi-VM Networking for details on addressing and connectivity, and Switching Between VMs for console behavior.