VPL Execution servers

From Computer Laboratory System Administration
Jump to navigationJump to search

The UIS Moodle implementation contains the Virtual Programming Lab activity [1].

In brief, the Moodle server farms out software testing to execution servers. In our case the UIS runs moodle, but the servers run in VMs in the CL. The key servers are:

svr-vpl-exe-[1,2,3,4,5].cl.cam.ac.uk
svr-vpl-exe-dev.cl.cam.ac.uk

The model is that UTOs get access to svr-vpl-exe-dev to set up and test their moodle VPL assessments. When happy they can run a command to deploy their changes to the live servers.


Adding a new user to the dev machine

On the svr-vpl-exe-dev machine:

  • Create the user as normal on the system
  • Consider giving sudo privileges (prefer not to: only really needed if they intend to install extra packages and you won't be around to help them)
  • Add them to the group cl-vpl
  • Create a subdirectory for the course under /usr/share/CST-VPL/[YEAR] (YEAR is the current academic year, 1718 for example). The course name should be camelcase (no spaces). e.g. PreArrivalJava
  • Set the directory to be group cl-vpl and group readable

They can now edit under that new directory and deploy it to the live servers using vpl-update-live-servers as per the instructions in the teaching wiki.

The SSH/rsync setup of the various machines

  • The svr-vpl-exe-[1,2,3,4,5] have a user vpl-sync that is used to control syncing from the dev server. They should not be directly accessible over SSH by users except in special cases.
  • The svr-vpl-exe-dev machine contains a key used to access the live servers. No passcode is set. It is in /etc/ssh/vpl_rsync_key.*. There is an entry in ssh_config as follows:
Host svr-vpl-exe-*.cl.cam.ac.uk
       IdentityFile /etc/ssh/vpl_rsync_key
       IdentitiesOnly yes
  • Each of the live servers has this key in their authorized_keys. There is also a restriction on what can be run. e.g.
from="*.cl.cam.ac.uk",command="/usr/bin/rrsync  /usr/share/CST-VPL/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDSbsrqQYF63cR9V6FMuFO+et4XGokon1z7IetA0oiez+MTEXPr+EhzSVXMtoThsvCSgWj+gcCee6y3uyYHBtZ2TR4QHxbhHjsqiGDbTWJYyRe6qt97BjeMXN1nfqkH6k4aV2xaQxAG5qlKZEkq6Me8VneOUp5TP9KTOY0U1oj1CgbSF0zXH8FDY5P9LUpMqrH8Xn6YszpdeXVHwq08eQAqByVauWeTK3p8vWWfLL6HYjk0HuXkJXwSlKmDUWq4QKZDnUuQUp9udMhQlOHBNPLzF12/fDX+G7gfHOo4PObM36h9Wa0VMS3V+Cg1hZC+1jxImRGm/eWrOLvvbAerzW5H VPL rsync update key

  • This uses rrsync as per [2]

This setup allows anyone with an account on the dev machine to rsync the /usr/share/CST-VPL folder (only) to the live machines.

Certificates

Note that the UIS Moodle instance uses https only. This has a knock on effect that the sockets used to communicate between moodle and the execution server must be wss. There is currently a certificate in place for the various VMs