Overview

Inspired by the challenges of lockdown, but relevant to any situation where a student needs/wants to complete labs remotely.

It can be challenging to carry out various lab exercises under remote conditions, mainly around setting up required software.

Papers like INFO 201/202 are fairly straightforward:

• JDK, NetBeans and PlantUML are available for all platforms (with varying degrees of platform-specific stupidity).
• Embedded H2 is sufficient for the database aspects.
• Department GitBucket server handles the VCS back end and is visible outside campus.

This means a student can be completely self-sufficient. All of the relevant tools are also available either through the student desktop (JDK, NetBeans, H2) or online (PlantUML editors). The only potential issue is the ongoing weird traffic shaping going on when accessing GitBucket from off-campus. If there are any largish files in the repo (>100KB) then things can stall out; probability of stalls increases with file size. For example, this is a recurring problem for some students when downloading the TiddlyWiki, and I have hit the same problem with my own repositories. If you keep trying it’ll eventually go through. Chris Edwards is following up with ITS about this.

It’s more challenging to provide a consistent experience for a paper like INFO 408 that uses multiple tools and back end servers (e.g., Oracle, MongoDB, Python, OrientDB). We want to avoid the situation of students haring off to all kinds of random online services which might or might not work as expected.

A student equivalent of the staff VPN would help us a lot. There was some mention of this during the alert level 4 lockdown, but this seems to have quietly fallen off the radar since.

Student Desktop

Works well for:

• Java development: see above
• Oracle: department back end at info-nts-01.otago.ac.nz + DBeaver via Info Sci “tool injection”
• Single-node MongoDB: department back end at ismdb.otago.ac.nz + mongo shell inside ConEmu via Info Sci “tool injection”

Not so workable for:

• Multi-node MongoDB clusters
• OrientDB

Python can be made to work, but is a bit messy.

Docker

Docker images are readily available for most of the required non-commercial tools (Oracle is an obvious exception), and it’s not hard to create new ones. Docker-compose can help simplify things as long as it’s installed correctly!

Linux

Access to docker tools is likely to require root privileges (sudo).

macOS

Docker for Mac is quite memory-hungry. It typically munches about 3.5GB of RAM when idling.

Windows

Docker for Windows requires you to explicitly authorise sharing of host directories with containers. This leads to often uninformative errors about sharing being disabled or similar. You can add directories under the Docker app sharing settings.

Recent versions of WSL should have enough of the relevant Linux kernel bits to be able to run Docker natively (but see Linux notes above), i.e., no need to install Docker for Windows.

VirtualBox appliance

This has a lot of potential as a general solution. We can easily create a small base image based on Alpine, and can even make it “pushable” via Puppet. The core tools required are:

• Docker
• Puppet
• Probably Python + virtualenv tools? (core Python should get pulled in alongside docker-compose anyway)

VirtualBox seems much less memory-hungry on macOS in particular.

What would be an appropriate maximum size for the VM disk image? (Bearing in mind this is likely to be run on lesser-spec’d laptops.)

Mark George notes: The maximum VDI size for VirtualBox should be on the larger side. I made a mistake with the first version that I gave the INFO 303 class and only made it 2GB which was plenty for the Docker lab, but too small for the Jupyter/Spark lab. Given the disk only grows on demand, I don’t see any reason to be stingy with this. I used 10GB for the second image. We should be careful to keep data sets, working files, and repos on the student’s host file systems rather than in the guest’s file system, and treat VM instances as disposable so that they can be killed to reclaim space as necessary.

Cloud solutions

… no.