Custom Linux Distro & VirtualBox Questions

@kannary100:

A) Can I generate the disk image in Linode and use it in VirtualBox or should I create the disk image in VirtualBox and use it in Linode? Or is it a two-way street whereby I can do either?

I am not really making a "custom" Ubuntu distro in any way different from what Linode has but trying to create a virtual appliance that I can duplicate as many times as I need locally so I can install and configure different stacks inside of it.

The major difference between a Linode image and a Virtualbox image is in the boot process. Virtualbox emulates/provides the entire x86 bootstrap by looking for a master boot record on a "disk" and executing it. The MBR is then responsible for finding and jumping to the operating system kernel.

Conversely, Linode (and most other VPS platforms) skip this by directly executing the kernel and providing it the location of a filesystem it can directly mount. Likewise, since the kernel expects a filesystem and not a partitioned hard disk, there is no partition table. Since it has to know exactly where the kernel is to execute it, it keeps it outside that filesystem as well.

So, while an x86/Virtualbox-compatible image has a master boot record, partition table, bootloader, and one or more partitions with one or more kernels known to the bootloader, a Linode image has none of these. You'll need to partition a hard disk image and copy the Linode image into a partition (don't forget to create a swap partition too), making sure that a kernel and bootloader are installed and configured properly.

It's doable, but a bit of a pain. The steps end up being a lot like what you would do to make a debootstrap'd system bootable.

> B) Could I run a desktop version of Ubuntu on VirtualBox and then import it into Linode as a server. The notes on the link above read:

…

No sure if this is related to my question, but it appears my wishful thinking tells me I could. I wonder if anyone would be kind enough to set me straight.

I don't see why you couldn't. It will have a lot of extra baggage – at least a kernel and the 'userland' bootloader tools, as well as all the "desktop" stuff if you don't plan on using it as a desktop -- but having extra parts is easier to deal with than having missing parts.

> C) Once created and uploaded to my node? Can I clone it like any other distro and move it over to other nodes using the standard Linode procedures? My idea is that I would end up with a node acting as a sort of "repository" with multiple disk images of virtual appliances that then I can copy over new nodes as needed.

You can clone it no matter what, but if you want to use the rest of the standard tools (especially resize), make sure the disk image on Linode's end is created as an ext3 partition via the dashboard. (And, of course, make sure it actually is ext3 – don't go and mkfs it to ext4 and expect the backup service to be happy.)

> Linked to this issue indirectly I have one last related question:

Can the cloning and copying of a disk image across nodes be automated using stackscripts? Say: Take Disk Image A in Master Node >> Copy to Node #x >> Set as boot image.

This is the part of the post where I suggest a better alternative :-)

There are a few major problems with this approach:

1) Disk images are big. You probably won't be throwing 16 GB images around, but even 1 GB starts to get a little network-heavy, especially if you're storing/developing the images at 'home'.

2) Disk images grow stale. You don't want to leave your static "gold master" booted and running, because running systems are living systems and living things can't be static. However, your master will not get security updates and bug fixes unless it is running. So, you end up having a process like "clone master image -> boot -> quickly apt-get upgrade -> fix that setting i forgot -> …" and by that point you're thinking "wtf, this isn't saving any time at all."

3) Along the same lines as #2, you will inevitably find that you forgot some important thing ("doh! left PermitRootLogin turned on!") or you have some new hotness you'd like to use going forward ("i want to use etckeeper from now on").

As such, rather than having gold master images, I would recommend using automated tools to take a barebones OS image (like, say, Linode's images) and bring them to your desired configuration. This starts down the path to "configuration as code," where you treat configurations as you would treat source code: a collection of human-readable instructions that are used to produce a machine-native product. There are a variety of tools to manage source code workflows, the most critical of which are version control systems. You seem a sensible person, so I have no doubt you would recoil in horror at the thought of developing software in the absence of version control; why not take advantage of this for your deployment, too?

There are a lot of systems out there to do Configuration Management (as the kids call it these days). Linode's Stackscript feature is one of them, as you probably guessed, and it's great for what you're trying to do. If your needs turn out to be more infrastructural, Wikipedia has a list of systems, as well. My current major project is using Chef, which doesn't just deploy systems but also verifies that running systems are configured properly every 30 minutes. Our Chef repository is currently 9.3 MB and has enough code to fully describe two types of application servers, MySQL master and slave servers (with automatic synchronization!), load balancers, memcached servers, and Solr search servers, and (most importantly) automatically discover other servers in the infrastructure. That's 9.3 MB for what would be seven distinct images. Combined with fabric and libcloud, we can have a new server deployed and bootstrapped on any VPS provider(*) in about ten minutes, starting from a barebones Ubuntu 10.04 LTS image.

This all took time to get set up, running, and tested, BUT so would any other approach. Plus, everything is text-based and checked into SVN, so we have a complete record of every change made and can take advantage of conflict resolution and all that. It has also opened up new avenues of cooperation between the development and sysadmin people, since us sysadmins now have to eat the dogfood we've been feeding the developers for years. :-) -rt

(*) Any provider supported by libcloud, at least.