Chapter 1 First Login
The box, the shell, the tree, packages, the network, PID 1, git over SSH, the disk.
In plain words
Imagine you just moved into a flat in a building where every light, lock and pipe is controlled by typing notes to a caretaker through a slot in the door. Before you can fix anything, you need to know which flat you are in, where the rooms are, how to ask for a spare key, what the building's address is, and who the head caretaker is.
That is this chapter. The flat is oncall-lab, the slot is SSH, the caretaker is bash, the spare key is sudo, the address is 10.64.0.2, and the head caretaker is PID 1, systemd. Every later chapter assumes you can move around this building without looking at the map.
Why it matters on call
Almost every platform job starts on a Linux shell: a server that stopped answering, a machine that ran out of disk, a box you SSH into to check a log. In those moments nobody has time for "which directory am I in" or "why did my redirect lose the errors". The basics in this chapter are the ones people get wrong under pressure: running a relative rm in the wrong place, reading $? one command too late, sudo echo > file failing, not knowing that exit 137 means the program was force-killed.
It also sets up the lab you will use for months: identity, packages, network, git over SSH, disk. When something breaks later, you will already know how this box was put together, which is half of debugging it.
Lessons
- Where you are
- The tree
- Making things
- Driving the shell: exit codes, chaining, redirection
- Asking the box: type, which, man, --help
- Packages and sudo
- Network identity
- Who's in charge
- Git identity and an SSH key
- The disk you were given
13 hands-on labs (missions, incidents and drills) run in the terminal: Open this chapter in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.
Questions people ask
Why learn on a VM when my Mac already has a terminal?
Because macOS is Unix but not Linux. There is no systemd, no /proc, a different kernel and different behaviour for half the tools (the Mac's sed, ps and date take different flags from Linux ones). The servers you will work on run Linux. Learning on the real thing means the muscle memory transfers 1:1 instead of needing a translation layer in your head.
Is this simulator enough, or do I need the real VM too?
Use both. The simulator gives you broken situations on demand (full disks, crashing services, stuck programs) that would take an hour to set up on a real box. The VM proves the commands are real and shows the small differences (for example Ctrl+R history search works there). Anything simulator-only is labelled (simulator). A good habit: when a mission teaches a command, run it once on oncall-lab too.
Do I need to memorise all the flags?
No. You need a small core cold (ls -la, cd -, mkdir -p, redirection, &&, $?) and the reflex to ask the box for the rest with --help, man and type. Interviewers and incidents both reward knowing what a tool can do and where to look, not reciting option letters. The flags you use every week will stick by themselves.
What is the difference between being root and using sudo?
Root is the account with UID 0; the kernel skips most permission checks for it. sudo lets your own account run one command as root, asks for your password, remembers it for 15 minutes and logs every use. On Ubuntu the root account has no password at all, so sudo is the normal way in. Staying as learner and borrowing root per command is safer: mistakes you make without sudo can only hurt your own files.
Why does this chapter bother with git and SSH keys?
Because everything you build in this course lives in a git repository on GitHub, and on a server you push over SSH with a key, not with a password. Making the key, trusting a host fingerprint and switching a remote from HTTPS to SSH are things you will do on every new laptop and VM. Doing it by hand once means you understand the error when a push says Permission denied (publickey).