Top link
CSE Mark II Invigilator
CSE Mark II Invigilator

VirtualExam (vx)
Administration

Things to write about:

  • Restart the exam for an individual user

Do not rm -fr a gaol!!

If nothing else, this is one of the most important things to learn about the VX environment (and, in fact, its predecessor priv gaol).

All the goals are located in /var/gaol on the back end exam server.

The reason why you don't just do an rm -fr on any gaol is that large swathes of each gaol are bind-mounted in place from the top-level file system. This means, for example, that /lib in the goal is actually the server's real /lib, and doing an rm on it is asking for major trouble should you succeed (such as if you run rm -fr as the root user). What you can easily delete on the host's file system by doing this includes:

Don't even do an rm of a gaol as the class exam account user!

Because you can take out:

See this page for tools which will do the job right.

If you do commit a naughty

If you do delete things while gaols are still operating, such as in-gaol mount points, you may end up not being able to actually delete the goals properly anyway. If this is the case, you have two options:

  1. Reboot, and then try and delete the gaols using the proper tools, or
  2. Run conform and then try step 1.

Auto-login / auto-creation of a student for testing

When testing the VX environment it can be rather onerous to use a valid zID and zPass to start each exam session. Auto-login bypasses this step.

Auto-login is enabled by creating an empty file in the class exam account home directory: $HOME/etc/autologin. This can actually be any file system object — file, directory, socket, whatever — it only needs to exist.

When this file exists, vxuserlogin does not prompt for or validate a zID, zPass or UID. Instead, it makes them up without stopping. And it makes them up like this:

Creating of the gaol then proceeds as normal, and this new (fake) zID becomes the one patched into the gaol's /etc/passwd, etc.

Persistent little devils, aren't they?

By design, gaols — and the processes started in them — only go away if things go smoothly, such as at the end of an exam when the students log off.

If something abnormal happens, the gaol and the processes stay around so that someone (such as yours truly) can conduct some forensics and work out what happened.

This means that it can be difficult to get rid of a gaol. If you are, say, the root user and you think that sending a signal to the gaol's window manager is a good way of getting rid of the gaol because a student can usually end/log out of an exam by selecting some menu item which causes the window manager to exit, then think again. Kill the window manager with a signal can be seen as abnormal and the gaol goes into "stubborn" mode and then refuses to go away.

If you do have a gaol that you do want to go away, perhaps because the student has walked away without logging out, or they've turned off the lab computer which was displaying their exam session, here are some official ways to do it:

  1. Kill the X server running on the lab computer (or Xvnc, if you're using using a virtual screen/keyboard/mouse via VNC). This closes the connection which the window manager is using, which will usually cause it to exit cleanly. This will trigger the normal gaol cleanup and termination.
  2. Use the programs mentioned on the Tools page to brute force the gaol into submission.

Cleaning up after an exam

After all gaols have been shut down (make sure of this!):

  1. cd /home/<class-exam-account>/currentexam || exit 1
  2. cd var || exit 1
  3. rm -fr *
  4. cd ../work || exit 1
  5. rm -fr *