Everyday Linux commands lab: the thirty commands engineers type from memory

This lab gives each student an Ubuntu machine of their own and five short lessons on the commands that are quicker to know than to look up: moving about, making and reading files, searching a log, stopping a process, packing an archive, fetching from the web, and logging in to another machine. Nothing is installed on the student’s computer, and nothing they do can harm anything but their own copy.

What students learn

Moving about with pwd, ls and cd, and making, copying, moving and removing files. Reading text with cat, head and tail, writing it with the signs that send output to a file, and searching it with grep and a pipe. Permissions: reading the rwx columns of ls -l and letting a script run with chmod. Processes: finding one with ps, stopping it with kill, and why kill -9 is kept for the one that will not stop. Disk and memory with df, du and free. Archives with zip, gzip and tar. Fetching with wget and curl. Becoming another user with su and sudo, logging in with ssh and copying with scp, installing a program with apt and looking after a service with systemctl, and editing a file in vi.

The rare and complicated commands are left out on purpose. They are quicker to find with a search or an assistant when they are needed.

What is on the machine

A log in /var/log/test.log that is written to every two seconds, so tail -f has something to follow. A zip, a file to compress and a small tree of folders. A folder called scratch that is safe to delete from. A small web server on localhost that wget and curl can fetch from, so no lesson depends on the internet. Two background processes to find and stop, one of which ignores a plain kill. And a second account, dev, reached with the name devbox.

The second machine is the same VM under another account, and the lessons say so. The commands are the ones used on a real server, and a key is already set up so that a button can run them with no password to type.

Run it in your browser

VM labs are set as a lab task in a module, and the sample is on the lab’s page. The machine is small: one CPU, 1 GB of memory and 10 GB of disk.

  1. Add the lab. In a module you teach, add a task and choose the Ubuntu VM lab card. The page shows a short description of the machine instead of a compose file.
  2. Start from the sample. The page offers ready-made labs to start from. Choose Everyday Linux commands. Using a sample replaces the text, and Undo brings yours back.
  3. Publish and start your own copy. Publish, then Start. The lab’s setup script installs a few small programs from Ubuntu’s archive and leaves a log, an archive, a web server and two processes the first time the VM starts, in under a minute.
  4. Open the terminal. Open its terminal and read README.md in the home folder: it lists what is on the machine. Then open the first of the five lessons.

A basic lesson on this lab

There are five short lessons, each worked in this lab: Everyday Linux 1: Move and make, Everyday Linux 2: Permissions and removing, Everyday Linux 3: Logs and processes, Everyday Linux 4: Archives, disk and the web, and Everyday Linux 5: Users and other machines. Each stands alone, starts by going to the home folder, and has a hook, an I can outcome, key words, a starter, a check after each idea and an exit check.

A Run button types its command into the VM’s terminal and shows what it printed. A command that never ends by itself, or asks something, such as tail -f, su or vi, is marked Type this, and the student types it in the terminal. The last lesson ends with a cheat sheet to keep.

How it is used in class

The lab marks nothing, so it suits a first lesson on Linux, a revision session or practice before a lab that is marked, such as Linux administration.

  1. Hand it out. Assign the lab and the lessons like any task, with a due date if you want one. Each student gets a VM of their own, kept between sessions.
  2. Watch them work. The terminal beside a lesson is the student’s own, and you can watch it or take it over from the class list while they type.
  3. Mark it yourself if you want a mark. The lab has no check script. If you want a hand-in, ask for something small, such as the output of a command they ran, or a screenshot of the log with the error line found.

The definition on GitHub

The file is the whole lab definition, the same text the platform runs: size, setup script and README. Copy it and add a file or a service of your own to make a lab for your own class.

Questions people ask

Is there a second machine for ssh and scp?
It is the same VM under a second account, dev, reached as devbox with a key already in place. The commands and what they print are the same as for a real server, and a lab with two machines is a larger one to start.
Can students harm anything by deleting files?
Only their own copy. The lessons delete from a folder called scratch, and if a student breaks the machine they can stop the lab and start it again.
Does the lab need the internet?
No. Downloads come from a small web server inside the lab. The machine reaches only Ubuntu’s archive, PyPI, npm and GitHub, and nothing else on the internet.
Is the everyday Linux commands lab marked automatically?
No. It has no check script, because the lessons are the activity. Set a small hand-in of your own, or move on to the Linux administration lab, which is marked.