Creating an Ubuntu VM to distribute

Question

I'm a TA for a programming course and tasked with creating a virtual machine image based off Ubuntu 14.04 LTS with all necessary software (for C++ and Python development) preinstalled such that the students all have the same virtual system running and we avoid the struggles of getting everything to work on a variety of different machines and operating systems. We intend to use Virtual Box as the host VM software as it is free and available cross platform.

Naïvely, I would just use the Ubuntu 14.04 LTS disk image, run it in my Virtual Box, install it to the virtual hard disk (VDI), set up a "student" account with a predefined password, install all the necessary software, shut down the virtual machine and distribute the VDI file. We'd ask each student to import the VDI to Virtual Box, run it and set up their personal account (or just use the default student account).

• Is the above procedure viable?
• What are the pitfall to look out for? We need this to be pretty much fool-proof. We expect 80+ students and are only four TAs, so we can't provide individual support.
• Are there disadvantages to using a dynamically allocated VDI-type virtual HDD?
• Is it ok for me to install Virtual Box's Guest Additions right off the bat or does it do anything host-specific?
• Is there a more elegant way to handle the user account creation? Ideally, Ubuntu would put them through an account creation wizard and have them set their passwords (as well as add them to the sudoers file) the first time they boot the image. This is not a priority, though. I guess having a default account is fine.

Solution 1

While this question is somewhat opinion based to a degree:

Yes this procedure is viable - I believe that it would accomplish what you are looking for and it is something I have done in the past with other linux distributions.

The only real pitfall is around disk spacing... make sure that your students machines have sufficient disk space to handle the size of the Virtual Disk. Also, ensure that you keep a copy offline on at least one machine so that you can use the template/reference disk to quickly recreate a disk when a student kills their machine.

The disadvantages to a dynamic disk is that the host OS has to keep allocating more and more disk space as the VM grows with data/updates. This has a performance overhead which can be a headache at times - especially if you are running on a low powered VM (Host machine power minus power being used to expand a disk does tend to make VMs lag a bit).. it also potentially makes then unportable (not all machines in your lab may have 100GB+ once a student has messed with their VM)

Guest addons aren't machine specific.. they're pretty much a driver set. When you import the VM into a new host, the VM drivers will detect and tweak your hardware to work on the new host.

Elegant user creation - not sure, maybe a script which runs on first launch and asks a user to create a new account before the script self destructs? I'll do some digging and get back to you when I have 5 mins to spare.

Hope this at least partly helps.

Solution 2

Answering your question exactly, if you need to tailor the VM and hand them a deliverable VirtualBox VM, I recommend using Packer to prepackage the VM with all the required dependencies. It is built for just this purpose and allows you to spin up an image from an ISO, perform any provisioning you want against that image, and then creates a deliverable VirtualBox VM image. This is good for you too because it documents exactly what was done to the deliverable in case you ever want to reproduce it/add something to it. Also, you can check the project into a source control system and make changes. Here's an example of that being done to get you started.

However, if you want them to get running quickly, I recommend using Vagrant and distributing to your students a Vagrantfile that performs the desired provisioning you require on a standard Ubuntu image. This has several advantages:

• Vagrant works out of the box with VirtualBox and will handle all the hard parts for the students such as setting up shared folders so they can copy files easily between the VM and host machine, configuring networking so as to allow internet access to the box for them, etc. This also saves you the time of having to document/debug VirtualBox setup issues for them.
• A Vagrantfile is much smaller than a deliverable VM. If you want to change/add something to the VM half way through the course you don't have to rebuild a new VM, just give them an updated Vagrantfile.
• If they mess something up beyond their ability to repair it, they can painlessly destroy/redeploy the VM again
• A Vagrantfile will show your students exactly what was done to the VM so that when the get to the point where they understand enough, they can see what's going on under the hood and possibly learn from that too.

Here's an example Vagrantfile showing how to do some provisioning on a Ubuntu 14.04 image.

Solution 3

Perfectly feasible. The alternative would be Vagrant, Puppet, Chef or something similar to build the VM's from scratch but that is a lot of work to setup.

The development team on one of my sites does the same to get new developers quickly up and running.
1 pre-set account (with sudo-rights) in the image and a short instruction-document with the steps they must take to create their on personal account.

Please note: You most likely need network/internet access inside the VM. That can be either bridged or NATted onto the host. Regardless which you choose, you will have to instruct your students how to configure the host side of this. Just setup the NIC inside the VM as DHCP device. That is a safe starting point for most configurations, even if the user later must manually configure a static IP address.
Putting a static IP address in the VM is really asking for trouble. It is bound the be in use already by another VM getting online on the same LAN...

Comments

[ChrisInEdmonton]

Note that you must include an offer for the source code, as you are distributing software under the terms of the GPL.

[Jonas Greitemann]

@ChrisInEdmonton Good point. Since I do not write any code myself, is this technically a modification or is it just redistribution? Is it sufficient to point the students to the Ubuntu or third-party sources should they ask (they won't) or am I legally obliged to provide the sources proactively? Does it matter that I do not publish the image but rather provide it to a limited audience with restricted access?

[ChrisInEdmonton]

I'll simply point you to the GPL as I'm not a lawyer. It's very unlikely to become an issue here. :)

[Markon]

I would say that you don't have to do that together with the Ubuntu image itself: gnu.org/licenses/… Just write somewhere in the instructions how to download the source code.

[user]

You may want to carefully review Canonical's intellectual property and redistribution policies before doing this. While GPL software is free to redistribute with source, and almost every other license you'll find software licensed under in a typical Linux distribution allows redistribution under reasonable terms, at least recently there has been some controversy about Canonical's IP policy.

[mckenzm]

Technically you have to include the offer, and keep a miror copy the source of your build at the time of the build. You do not have to keep source for packages your users update themselves. It is not enough to rely upon other mirrors or upon Canonical. Remember Mepis. In theory you have to supply source according to the GPL for a duration after distribution (not the duration after the original release). I once gave a donation to Puppy Linux and got the entire build procedure on CD unsolicited by post so people do take this seriously. If you form a club there is no "distribution" per se.

[MSalters]

VBox Guest Additions are not redistributable !

[MSalters]

@mckenzm: No, you don't have to include an offer. It's one option, but another option is to straight away include the source. If you do this, you do not have enduring obligations.

[Jonas Greitemann]

Thanks, it does help quite a lot. My main concern is not to mess up the basics. Don't spend too much time on the user creation thing. It's really not that important. I just thought, since I was asking anyway, I might as well ask if there is some built-in mechanism to handle it, as I assume it's a pretty common problem.

[Fazer87]

absolutely - and it's entirely possible that there is a built in solution, so i want to find it.

[Jörg W Mittag]

The "lot of work to setup" depends on how often you have to create images, though. Are you TAing the same course next semester again? Are you maybe TAing a similar course with a different language next semester? Do you want to make life easier for your successors? C++ compilers have bugs that get fixed in later versions. A new C++ standard comes out in 2017. Remember, a programmer is a person who spends 2 hours to write a program to perform a task in 2 seconds that would have taken 2 minutes by hand. ;-)

[Tonny]

@JörgWMittag Of course, you've got a point. But if you're not familiar with Vagrant and the like the learning curve can be pretty steep/time consuming. Personally I would probably go for the VM solution for a quick solution this semester and during the semester spend some time developing into the other solution for a long-term approach.

[user1937198]

Regarding network access, the distributed VMs will probably have identical MAC addresses. It may not be a problem with NAT, but it is a good idea to reset the MAC addresses anyway.

[Tonny]

@user1937198 The MAC is set by VirtualBox/vmdk, not set in the VDI itself. If you point and click a new VM together in VirtualBox and then add the VDI file you will get a fresh MAC. (By import from OVA you'll be asked wether or not to reset the MAC.) But you're right. It something else to consider and certainly a problem if the network is run in bridging.

[Sandy Chapman]

Vagrant and/or Packer are the way to go for this.

[Steve Barnes]

@JörgWMittag the point of a programmer spending 2 hours writing a program to do in 2 seconds what it would have taken him/her 2 minutes to do my hand is once it is done, if done correctly, anybody can do the same in 2 seconds, reliably and repeatedly. So 120 minutes are bought back after it is used 61 times used even assuming everybody could do it in 2 minutes.

[Tonny]

@SteveBarnes I espcially agree with you last phrase: No matter how good the working-instruction is, people will get it wrong when they follow it. They skip steps (or do them in wrong order), make typos in the commands they need to execute or they think they know better and deviate from the script. If it is automatable (my spell-checker isn't sure if that is actually a word) the best approach is still to automate it: No room for error.

[Steve Barnes]

@Tonny - My favourite is people trying to make sure that they get things perfect by pasting from MS-Word or MS-Outlook to the command line - the automatic changes such as minus to hyphen and double quotes to open & close double quotes inevitably cause chaos because they end up with something that looks correct but isn't. The number of times I have had to say or write "Do not copy/paste, Type the following:"

[Tonny]

@SteveBarnes Oh yeah... Been there, done that. Even worse: Filenames with accented characters like ü or é. And, of course, the command-line uses a different code-page than the document. Try to explain that to the average user :-)