What happened when the lab locked.

The setup

Exams in this course run as programming contests on a self-hosted DOMjudge server. No single room holds 239 students, so the exam ran across four labs at the same time, about 260 machines in all.

Every machine in all four labs, spare seats included, was locked from one jump host, with the judge as the only resource available to students. Seating came from the roster; each student got a different machine and different neighbours.

During the exam

Some students tried Google, GitHub, Gmail, cppreference.com, and Wikipedia during the exam. The proxy blocked all of it. Each blocked request was logged; students saw no alert or warning on screen and the exam carried on without interruption.

Afterwards

The lab team reviewed proxy logs from 257 of the 259 machines: 231,433 lines in total. There were zero blocked requests to the real judge, so the rules never got in a student’s way.

All 4,105 evidence files from the machines were checked against the jump host and matched byte for byte. The labs returned to normal teaching use the next day.

What went wrong

The labs dual-boot Windows and Ubuntu. Windows stores the hardware clock in local time; Linux expects UTC. On some machines Ubuntu woke up five and a half hours in the future, and the campus network blocked the time synchronisation that would have corrected it.

SafeExamOS creates a local certificate when it locks a machine. On those machines, the certificate carried a future timestamp, so the browser flagged the connection as insecure. Fifty-three machines were affected.

What the team did

Students on affected machines moved to spare seats, which had been locked before the contest for exactly this reason. Twenty-seven people moved; their logins and records came with them.

Meanwhile the team identified the cause, applied the fix to all 259 machines during the exam, and left every machine exam-ready. Eleven issues were logged and closed the same evening.

What changed

The clock fix is now part of the dual-boot lab setup, and dual-boot installs are a requirement for the public release. We include this account because an honest record of what broke and how it was fixed is more useful than a promise that nothing will.

The question

The instructor wanted to know one thing: was each submission made from the lab, by the student at the assigned seat? CodeChef records submissions; SafeExamOS records which seat sent which request. Line them up and you can check.

The first pass flagged sixteen submissions with no matching request. With a remote proctoring tool, that is the point where you get a video clip and a suspicion score.

The answer

A closer look showed all sixteen were compile errors, which the judge records differently from accepted submissions. Each one had a matching request in the lab logs, from the correct assigned machine, within a second of the judge’s timestamp. The audit found no evidence of cheating.

The course also published a simple rule: any submission made outside the lab during the contest window counts as practice rather than an exam attempt. Students know where they stand, and nobody has to be watched to enforce it.

The setup

The host university’s lab was not one the team had set up before. They shared an installer image and a short handoff guide, the local admins installed it, and a small machine in the lab became the jump host.

From there the team locked the lab over a VPN for two CodeChef contests, with rules that allowed those contests and nothing else on the site.

Handing it back

After the second contest the lab was restored and checked. On every machine inspected, the proxy was off, the exam account was gone, and the everyday account was untouched. The lab returned to the university’s normal use.

Why

Machines fail during exams. A fan dies, a disk complains, someone kicks a cable. If the spare seats are already locked, moving a student means pointing their login at a new seat. The machine is ready; there is no scramble.

How it went

110 machines across two labs were locked in a single run before a 20:00 contest, then rebooted and checked again: 109 came back locked and verified. The check caught the one that did not, so no student ran into it.