Final Report for Project 239

This is the final report for project 239, DICE virtual image with teaching software for students - trial.

What was done

These were the project's main stages of work:
  • Getting to grips with using DIY DICE.
  • Learning how to use VirtualBox (installation, configuration, image exports and imports) and tackling instability problems.
  • Getting networking working both on and off the Informatics network.
  • Arranging for DICE account login to work from anywhere on EdLAN.
  • Providing a facility which provisions local DB files with user account data from LDAP.
  • Getting AFS to work from outside the Informatics network.
  • Writing documentation and maintenance procedures for computing staff.
  • Writing documentation and maintenance procedures for users, and providing user maintenance facilities.
  • Testing and adjustments.
  • Working out probable user work flows and adjusting tools and documentation to suit.

What was delivered

These were the project's listed deliverables:
  • Can be used for simpler student work. This was delivered. Virtual DICE has most DICE software so can certainly be used for simpler student work. The main constraint as distributed is lack of memory (the image has 1GB of memory) but that can easily be changed by the user.
  • Runnable on personal machines. This was delivered. Virtual DICE runs on VirtualBox which runs on common desktop and laptop OSes.
  • Runnable on IS machines. This was not delivered. Extra work would be needed to deliver it. See Use in IS Labs below for more details.


The management information for computing staff is at Virtual DICE Management.

The information for users of Virtual DICE starts on with subsidiary pages

What was learnt

Bits and pieces about DIY DICE, VirtualBox, LDAP.

Project proposal v. actual work

The project proposal suggested that the trial version could be used to gauge interest. We noticed that Virtual DICE got several dozen downloads by HTTP in the first few days after it was announced to students. It was also made available directly over AFS: we don't know how many people obtained their copies that way.

The proposal raised the topic of image distribution systems, although it stressed that a scalable solution would not be expected to be delivered as part of this project. However since the images are distributed from AFS it seems likely that were a simultaneous mass download to be expected, the load could be spread quite effectively across the AFS servers by pointing the download location's mount point at multiple copies of a read only volume.

The proposal suggested two ways to tackle the project. Only one - basing Virtual DICE on DIY DICE - was tried in the end. The other - building up from a completely standard OS - was not. Why not? It was felt that that approach might be more problematic:

  • The VM would need configuration, for example to give access to AFS or to configure software appropriately. We might need to introduce some sort of configuration method or software.
  • It would probably help, and minimise user confusion and subsequent user support cost, to have exactly the same versions of software as on DICE. Support for this might be time-consuming. (Unless, for instance, use of the VM in IS labs and of the Informatics labs was segregated by course or year somehow, with for example all first year students using the VM in IS labs as their sole recommended computing platform for course work, and the Informatics labs being used by other years?)
  • Alternatively the support cost of the software differences to DICE could be high.
  • Either way, we could expect some staff to find it hard to adjust to having two sets of student software available, one on DICE and one not; the incidence of student exercises being inappropriate for the available software or hardware could be expected to rise, together with the extra support costs which could go with that.
  • The possible confusion for students without much Linux expertise of using both DICE and another Linux, and coping with the differences between them.
  • Requests for individual support of images might arguably crop up more with stock Linux, if local config had to be added to e.g. configure software, access AFS, etc. Imagine that configuration being changed by OS or individual software updates for instance.

Having said that, an important reason why this approach was not tried was probably simply that the other approach - of starting with DIY DICE - was straightforward and worked well.

Use in IS Labs

Virtual DICE has effectively no security yet can accept students' DICE account details for AFS access. We therefore recommend its use only on secure personal machines. Use on shared IS lab machines would have to be done in such a way as to eliminate the risk of (for instance) an attacker being able to install spyware to illicitly learn student account details. For instance, it might be possible to have any VirtualBox read/write storage entirely in volatile media, completely wiped between each user and provisioned afresh from an image in read only storage.

Our NX service might be an obvious alternative to recommend for simpler student work in IS labs - though it might need more resources if it was going to be asked to cope with significantly more simultaneous student users than it has had to date.

Future Work

For users with a modicum of system admin experience, VirtualBox should not be hard to configure. The same is true of the simplified, scripted system admin processes presented with Virtual DICE. However it's arguably unreasonable to expect all of our students to have such experience. For those who don't, installing, configuring and maintaining a Virtual DICE instance may be rather difficult. To help those users, we should document the various procedures in a clear and comprehensive way, and preferably do it separately for each platform.

It is probably worth mentioning at this point that the late-in-the-project modification of the LDAP configuration (to allow Virtual DICE logins using DICE account credentials when connected anywhere on EdLAN) was prompted by would-be users' failure to understand the maintenance instructions as they then were. For instance, some users could not grasp the difference between the Informatics network and EdLAN, or between the Informatics and University VPNs, and viewed them as interchangeable even when the Virtual DICE instructions stated that they were not. This problem was tackled in two ways. The first was to remove most of the need to make such a distinction by changing our LDAP configuration. The second was to add explicit warnings in the documentation next to every single mention of VPN or network connections, where the difference between Informatics and University services was still significant.

Any use of Virtual DICE in IS computing labs would have to be carefully planned - see Use in IS Labs.

It's difficult to see how Virtual DICE in anything like its present form could be used to host online exams, given its complete lack of security, so if we did need to run online exams from the IS labs we'd probably need to either modify it extensively or look at a different solution. See also project 261: Lab Exam Virtual Machine Image.

Time taken

Period Hours
T1 2013 53
T2 2013 150
T3 2013 80
T1 2014 3
T2 2014 2
Total 288

I've attempted to put together which parts of the project took the most time, using my weekly time figures and the mentions of Virtual DICE in the MPU meeting minutes. There are a few gaps in both but here are the most time-consuming parts of the project that I did manage to figure out:

  • 25 hours: Struggling to install DIY DICE with PXE. Eventually got it installing from CD images instead.
  • 32 hours: getting the DIY DICE machine properly networked with DHCP and NAT. Making a guest login account. Finding that our LDAP info (for logins using DICE accounts) isn't available outside the Informatics network. Configuring 'sudo'. Making the disk size dynamic.
  • 29 hours: problems with AFS, and with an elderly Mac.
  • 14 hours: solved some issues from Neil
  • 13 hours: Have found out how to save Informatics LDAP information to local DB files, so it can be used off-network. Haven't yet worked out how to use it though. VirtualBox has been unstable. Home directories can now be made automatically on demand.
  • 20 hours: Problems importing images in VirtualBox. The first login after booting takes an age.
  • (unknown amount of time) the user can now save LDAP information to DB files.
  • 18 hours: Made the VM ready for people to test. Set up distribution of the images over AFS and the web.
  • 16 hours: first test results: need to drop USB support to avoid use of non-free VirtualBox module. First suggestion of a user maintenance script to update the image from time to time.
  • 44 hours: Virtual DICE now has its own login screen. The yum config is sorted. The user maintenance/upgrade script has been written. Lots of documentation was written. The RAT software was finalised. Discovered then circumvented a bug in yum.

If the project had simply provided a DICE-like VM which had student software, a guest account and basic networking, it would have been ready to test in about 60 hours. Add on (say) 10-20 hours for testing and another 10-20 for documentation, distribution and announcements and it might have come in at around 100 hours. This is almost exactly the three weeks originally budgeted for. Most of the rest of this project - the additional functionality - was decided on in response to tests of the first basic VM. This additional work should perhaps have been done instead under the auspices of the companion project Virtualised DICE image - follow on (276). Adding in support for DICE authentication, for AFS and for periodic updates of the software and the authentication data added complexity and extra work which took quite a bit more time and in the end almost tripled the length of the project.

-- ChrisCooke - 04 Aug 2014

Topic revision: r5 - 21 Aug 2014 - 14:59:40 - ChrisCooke
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies