Review 1 of 3 · Weeks 1 to 3 · plan two sessions
Toolkit review
Three weeks, one workbench: a version-controlled project, a Linux machine you administer over the network, and a lock on the door. This page is the theory of all three, compressed to what carries the rest of the course, with the self-tests the exam will feel like.
The map: three machines, two kinds of link
Week 1: Git's model, compressed
Git's entire mental model is four areas and the moves between them. The working directory is the files as they are right now. The staging area is the shopping basket: changes you have marked for the next snapshot. The local repository is the chain of snapshots (commits) on your machine, each with an author, a message and a pointer to its parent. The remote is the same chain on GitHub, shared and backed up. Every daily command is a move: git add promotes working-directory changes to the basket; git commit turns the basket into a permanent snapshot; git push sends new snapshots to the remote; git pull fetches and applies the remote's new snapshots. Commit and push are therefore different acts: committing is local and costs nothing; nothing reaches GitHub, or your partner, or the grader, until a push. Two parallel histories touching the same lines meet as a merge conflict: Git writes both versions into the file between <<<<<<<, ======= and >>>>>>> markers and refuses to guess; you edit the file to the version you want, delete the markers, then add and commit the resolution. Full story, diagrams included: Week 1's ideas page.
The Git command core
| Command | Move it performs |
|---|---|
git status | Show where every change currently sits; the first command of any confused moment |
git add file · git add . | Working directory → staging area, one file or everything |
git commit -m "message" | Staging area → local repository, as one snapshot with a message |
git push · git pull | Local ↔ remote: publish your new commits; fetch and apply theirs |
git log --oneline | The chain of snapshots, one line each, newest first |
git clone URL | Copy a remote repository, history and all, onto a new machine |
git diff | Exactly what changed and is not yet staged |
Week 2: the Linux models
Three models carry everything the terminal asks of you. First, the filesystem is one tree rooted at /, your territory at /home/username, and every command runs somewhere in that tree: pwd names the spot, paths are directions from it (.. up one, ~ home), and most "file not found" moments are really "wrong somewhere" moments. Second, commands are verbs with options and objects: ls -la, verb plus flags plus (implicit) place; learning twelve verbs well beats recognizing fifty. Third, the boot chain: power applied, the Pi's firmware loads the bootloader from the boot drive, which loads the Linux kernel, which starts services (SSH among them), which is why a headless Pi is reachable about half a minute after power without any screen, and why a corrupted boot drive fails before anything else can. Headless workflow in one breath: Raspberry Pi Imager writes the OS with hostname lastname-pi, your username and SSH enabled; the Pi boots on the bench network; ssh username@lastname-pi from the laptop, and the machine is yours. Full detail: Week 2's terminal page and its cheat sheet.
The command core
| Command | Does | Command | Does |
|---|---|---|---|
pwd | Where am I | cat file | Show a file's contents |
ls -la | List everything here, details and hidden files | nano file | Edit; Ctrl+O save, Ctrl+X leave |
cd folder · cd .. · cd | Move in; up one; home | cp src dst · mv src dst | Copy; move or rename |
mkdir -p a/b | Make folders, parents included | rm file · rm -r folder | Delete, no recycle bin, forever |
hostname -I | The Pi's address on the network | sudo command | Run as administrator, deliberately, not by habit |
Week 3: the security trio
Updates. The apt cycle is two distinct acts, and the distinction is exam-grade: sudo apt update refreshes the catalogue, what versions exist, installing nothing; sudo apt full-upgrade -y then installs the newer versions the refreshed catalogue revealed; sudo apt autoremove -y sweeps packages nothing needs anymore. Why it matters is Week 3's opening story: unpatched, default-credential devices are exactly what the Mirai botnet harvested by the hundred thousand, and an IoT course that skips patching trains the next harvest.
Keys. SSH keys replace guessable passwords with mathematics. ssh-keygen mints a pair: the private key, which never leaves the machine it was born on, and the public key, which you hand out freely; ssh-copy-id installs the public half on the Pi, and from then on login works by the Pi issuing a challenge only the private key can answer. No secret crosses the network at login, which is why a key cannot be phished in transit the way a password can. The same model, public key uploaded to the service, authenticated both your laptop→Pi logins and the Pi→GitHub connection.
Firewall. UFW's stance is default deny incoming: every service port is closed unless explicitly allowed. The iron rule of order: allow SSH's port 22 before enabling the firewall, because enabling first slams the one door you are standing behind, and a headless machine with SSH blocked is reachable only by pulling the drive. Verify with sudo ufw status verbose. The general principle behind all three: minimize attack surface, then verify the state, never assume it. Full pages: updates, keys, firewall.
Self-test: write the command
Paper and pen, answers covered. These are the exam's favourite shape: a described task, one line expected.
1 · Save the staged changes as a snapshot with the message "wire the button".
git commit -m "wire the button". No push happened; the snapshot exists only locally until one does.2 · Your partner pushed overnight. Bring their commits into your copy before working.
git pull. Pull before work, push after: the two-ended habit that prevents most conflicts.3 · Show which changes are staged, which are not, and which files are untracked.
git status. It answers "where does everything sit?" across all four areas.4 · Make the folder ~/iot/week8 even though ~/iot may not exist yet, then go there.
mkdir -p ~/iot/week8 then cd ~/iot/week8. The -p creates missing parents without complaint.5 · Refresh the package catalogue, then install everything newer, confirming automatically.
sudo apt update then sudo apt full-upgrade -y. Two acts: learn what exists, then install it.6 · Generate a modern SSH keypair, then install its public half on the Pi.
ssh-keygen -t ed25519 then ssh-copy-id username@lastname-pi. The private key stays where it was born.7 · In what order do you run sudo ufw allow 22 and sudo ufw enable, and what happens in the other order on a headless Pi?
8 · Show the Pi's firewall state, rules and defaults, to verify rather than assume.
sudo ufw status verbose. Week 3's habit in one command: after any security change, look at the resulting state.Checklist for this review
Check yourself
You committed twice but your partner sees nothing on GitHub. Which concept explains it, in one sentence?
git push. Two areas, one missing move.What do <<<<<<< markers in a file mean, and what is the three-step exit?
git add it, git commit the resolution.Why does a headless Pi become SSH-reachable with no screen ever attached?
Why is sudo apt update alone not an update, in the everyday sense?
full-upgrade performs the installation the refreshed catalogue makes possible. Running upgrade without update installs from stale information; update without upgrade installs nothing at all.