Linux administration lab: users, permissions, cron and systemd in your browser

This lab gives each student an Ubuntu server of their own to look after. There are four small jobs of the kind a system administrator does in the first week: add a user and a group, set the permissions of a shared folder, schedule a job with cron and write and enable a systemd service. Nothing is installed on the student’s computer, and a script marks the result, so you do not have to read each machine.

What students learn

Users and groups: making an ordinary group and an ordinary user with a home folder and a login shell, and putting the user in the group without giving the user administrator rights. File permissions: owner, group and everybody else, and the setgid bit that makes files made in a shared folder belong to the folder’s group. Scheduling: a job in the system cron folder, which has a user field that a personal crontab has not, and a file cron will silently ignore if it is written wrongly. Services: a systemd unit file, what it needs to be restarted on failure and started at boot, and the link that enabling a service makes.

The four tasks

Task 1 is a group called devs and a user called maria in it. Task 2 is the folder /srv/projects, which group members can use and nobody else can. Task 3 is a daily job at 02:30, run as root, for a backup script the lab provides. Task 4 is a service called heartbeat for a script the lab provides. The README the lab leaves in the home folder says what to do in each and gives no commands, no permissions and no unit file.

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 Linux administration. Using a sample replaces the text, and Undo brings yours back.
  3. Publish and start your own copy. Publish, then Start. The lab’s own setup script installs cron from Ubuntu’s archive and writes the two small scripts and the README the first time the VM starts, in a few seconds.
  4. Open the terminal. Open its terminal and read README.md in the home folder: it says the four jobs to do and gives none of the answers.

A basic lesson on this lab

Linux Administration Basics is a small lesson worked in this lab, which is an Ubuntu VM: each step is explained and has a Run button that types its command into the machine’s terminal and shows what it printed. A student asks who they are, finds that the team group does not exist yet, reads who may use the projects folder from its permissions and sees which scheduled jobs there are.

The lesson looks around and leaves the lab’s own task, doing the four jobs, to the student, so it hands out no answers. It is deliberately small: it shows a teacher what a lesson worked in a lab is, and the lab does the rest. Copy it into a module of your own to change it.

How it is marked

The lab has a check. It runs on a copy of the saved machine after a fresh start, so it sees only what the student saved, and it goes through the four tasks in order and stops at the first one that is wrong. It reads real state: the user and the group, the folder’s owner and mode and a file made in it by the new user and by somebody outside the group, the cron file in /etc/cron.d, and the unit file with the link that enabling the service makes. A user crontab, a folder opened to everybody, a service that was started but never enabled and a copy of the unit file in place of the link do not pass, and the first line of what the check printed says which task and why.

  1. Hand it out. Assign the lab like any task, with a due date if you want one. Each student gets a VM of their own, kept between sessions.
  2. Run the check. On a student’s row in the class list, press Run the check. It starts a copy of their saved machine that is not saved back, runs the lab’s check script as root and shows whether it passed, what it printed and when. The student is not told the result.
  3. Mark it. Read the first line of what the check printed: it names the first task that is not right and says why. Send the work back with a reason if it needs more.

The definition on GitHub

The file is the whole lab definition, the same text the platform runs: size, setup script, README and check. Copy it and add a job of your own, such as a disk or a firewall rule, to make a longer lab.

Questions people ask

Does the check run the cron job or start the service?
No. It reads what was saved: the cron file’s owner, ending and one job line, and the unit file and the link that enabling it makes. Whether the job fires at 02:30 is cron’s own business once the file is right.
Can students use the real administration commands?
Yes, which is the point. The student has sudo on a real Ubuntu machine, so useradd, chmod and systemctl work as written. The machine reaches only Ubuntu’s archive, PyPI, npm and GitHub, and nothing else on the internet.
Is the Linux administration lab marked automatically?
Yes. A script checks a copy of the saved machine after a fresh start, goes through the four tasks in order and stops at the first one that is wrong. The first line of what it printed says which task failed and why, so you do not have to read each machine.