TL;DRBoundaries are only important if they are respected. Guardrails are how we enforce them. Don't just set boundaries, install guardrails too.
My lab computers are scheduled to automatically shut down between classes.
While it could be obvious why this is the case, it ultimately ensures that accounts aren't left logged in and hogging resources for the next class, power consumption is reduced, and (most importantly) the room isn't a hotbox every single morning.
What I don't shut the machines down for is to prevent students from connecting to them remotely after school hours. Because the machines are shut down anyway, preventing ingress after hours wasn't something that was really on my radar.
Well... last week I learned to never underestimate the ingenuity of a teenager with a computer, a still-developing prefrontal cortex, and too much time on their hands.
This past week, one of my students figured out that if they set a userspace cron job to spam the shutdown -c command the second school gets out, they can keep the machine running indefinitely without raising any flags with any other students using that same computer. For the curious, here is the script they wrote:
#!/bin/bash
LOGFILE="/home/USERNAME/laston.txt"
while true; do
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Running shutdown -c"
echo 'Please have mercy!'
echo "I cannot shutdown since users are online, but I will do house-keeping when I'm finished. See you o/"
shutdown -c >> "$LOGFILE" 2>&1
sleep 1
done
I actually admire the creativity here. They set up a cron job (in their own user account, meaning no root access required) to run this script every minute. The script itself runs indefinitely, so the cron job is effectively a no-op after the first time it runs, and they even added logging to a file in their home directory so they could see that it was working.
What they did next, though, was set up another cron job to connect to a tailscale network and start a VNC server immediately after reboot (both of which were also userspace services, meaning no root access required).
Why might a student want to do this, you ask?
So they could work on their coding assignments after school without having to transfer files around. Via Git. That industry-standard tool that I teach them to use for exactly this purpose. I'd be impressed if it weren't for the lack of personal reflection as to whether or not what they were doing was a good idea and not just a fun one.
All of this is a good reminder that there's a fine line between guardrails and boundaries.
I didn't set guardrails to prevent these activities, so they cobbled together something that definitely violates my established boundaries (and the actual ethics contract they signed), but there was no ill intent so it's been a good reminder for me in the importance of clear communication (turns out, if students don't know what "ingress" means, they can't effectively follow a rule that disallows it without explicit permission).
Talks have been had and boundaries have been firmly reestablished (I hope), but I also made sure to add more hard guardrails to commands that 99% of my students were responsible enough not to abuse (in case you are curious, I updated the firewall to limit ingress to only the lab IPs—which means that some future client-server labs will be more limited—and I disabled all personal crontabs thanks to the cron.allow file, which I was previously unaware of).
Anything else I seem to be missing?
It's been well over 15 years since I managed a Linux lab, so there are probably some cobwebs in the "best practices" that still need dusting off.
--
If you like this post or one of my projects, you can buy me a coffee, or send me a note. I'd love to hear from you!