The MLN Project

Complex virtual machine management made easy

The Blimp: Using MLN to set up a information central

It happens often. You and your friends are in charge of a bunch of machines. This may be a conference, a LAN-party or some project you are working on. Then you realize that you need to gather your information into one spot in order to streamline your sysadmin effort. Everybody agrees, that a wiki would be nice, but no one has set one up. A request tracker and a weblog would be nice too.

A group of students at the University College of Oslo have created a MLN template for this purpose. It contains the following services: There are some gains in putting all of this into a vm.
  1. Flexibility. You only have to care about getting the vm up and running, the rest works.
  2. Security. The services are not running directly on your machine.
  3. Mobility. If you don't want it anymore, simply shut it down and move it to another machine and continue to run it there.
  4. Cleanup. Shut down the machine, and all services and databses are neatly packed in one bundle.
The MySQL and apache performance are tuned to suit running on a VM and for small crowds. Here follows a tutorial on how to set up a blimp from scratch in just a few minutes. It may seem like an extensive howto, but we wanted to be thorough. There is not much to it and after doing it once, you should master it.
We assume you have a Linux box running Debian Linux. You can use other distros too, off course.


This tutorial assumes you have a working user-mode-linux installation.
UPDATE: It seems that debian packages are shuffling around at the moment. Also, some have reported problems using the blimp without a SKAS patch on the host kernel which also improves vm security and performance. You can get the SKAS patch from here:
A more recent (but unofficial?) repository can be found here:

Setting up MLN

In this example, both a user and root need to use MLN, so we need to configure it for both. We'll let them share the directory for the templates, though.

# as root

mkdir -p ~/mln/projects

mkdir -p ~/mln/files

mkdir -p /opt/mln/templates

echo "projects /root/mln/projects" > ~/.mln

echo "files /root/mln/files" >> ~/.mln

echo "templates /opt/mln/templates" >> ~/.mln

# as a user

mkdir -p ~/mln/projects

mkdir -p ~/mln/files

echo "projects /home/kyrre/mln/projects" > ~/.mln

echo "files /home/kyrre/mln/files" >> ~/.mln

echo "templates /opt/mln/templates" >> ~/.mln

Notice the need for absolute path in the mln configuration file. When the templates are downloaded, we can register them into the MLN template system. (you only have to do this as one of the users, assuming that every user has write acces to the templates directory.)

mln rt -t blimp-V0.3.ext2.tar.gz

mln rt -t Debian-3.0r0-V0.5.ext2.tar.gz

You also need a root password in its encrypted form for the virtual machine:

mkpasswd blimp_password


Initial Decision: Networking

Before we go on, you will have to decide on how the vm shall be connected to the rest of the network. You have two choices, and both assume root access on the host where the vm is supposed to run.

Alternative 1: The bridge

Using this alternative makes the vm appear on the network just like any other host. It can come up using DHCP and even have a public IP address (if your subnet is public, also). The way we do it in mln, is to create a brigde interface on the host, connect a uml_switch to it and set write access to that switch so that othe virtual machines can connect to it. This approach is easiest to achieve if your machine has a static ip-address and no other fancy routes, like a vpn connection or such.

As root: 

mln enable_bridge

mln build -f examples/external-switch.mln

mln start -p external_switch

chmod 666 /tmp/my-global

Note the last command. Here we set the permissions for a file which is actually a socket belonging to the uml_switch. You may set more stringent permissions on it if you want. The main point is that the user running the vm later on has read/write access to it.

Now youre ready to write the configuration file for the blimp:

# basic configuration file for a blimp

global {

       project blimp


       #put your nameserver here: 

       $nameserver =

       $passwd	   = lEmXSNb8apZVQ


host zeppelin {


     term screen

     template blimp.ext2

     memory 128M

     swap 128M


     root_password $passwd


     modules {



     network eth0 {

     	     switch /tmp/my-global

	     address dhcp



Lets explain this configuration. In the global block, we set the name for this project, "blimp", and define two variables (which you should change the content of). Next we define a host named "zeppelin" and set it to start in a screen, use 128M of ram and a swap disk of 128M as well. One of the most important parts is that we use the template called "blimp.ext2". Notice that we omit the version number when naming the template. MLN will use the latest version of the tamplate if you have registered several versions or want to build a new one with a newer version of the template same.

We also set a root password and copy the kernel modules into the vm. The last part is about the network interface. It says to connect the interface to a switch with the socket located at "/tmp/my-global". The address will be assigned via DHCP. If you want a static address, then the network block has to look like this:

# example of a static IP

network eth0 {

	switch /tmp/my-global






Alternative 2: A Tuntap device

With this approach, you create a tunnel interface on your host and connect the vm to the other side of it. This approach is argued by some to be the best performance-wise. For the setup shown here, you need two static ip-adresses, one for each side of the tunnel. You also need to tell the OS to answer for arp-requests coming from the rest of the network to you vm, or else it would not be detectable by other machines on your net. The interface itself needs to be writable by the user running the vm. We'll call the interface "tun0" Here goes:

# as root

# vm-address:

# tun0-address:

root:# tunctl -d tun0 -u kyrre

Set 'tun0' persistent and owned by uid 1000

root:# ifconfig netmask up

root:# chmod 666 /dev/net/tun

root:# route add -host dev tun0

root:# arp -Ds eth0 pub

Again, you might want to consider more precise permissions on "/dev/net/tun".

The configuration file would look almost the same as above. The only change is the network block of the host. In adittion, we need to tell the vm to send out all traffic going to its subnet through the tunnel. It looks like this:

network eth0 {

	tun_iface tun0






startup {

	route add -net netmask gw


Building and starting

Before we build the vm, it may be wise to check out the configuration one last time. Use this command to see how MLN interprets the file:

mln build -s -f blimp.mln

If you recognize the configuration and want to proceed to build, remove the "-s" option.

mln build -f blimp.mln

The build proces may take a minute or two depending on the speed of your disks. When done you are ready to start the project:

mln start -p blimp

You will get a message, that the host "zeppelin" is started in a screen. Next, you may connect to its screen to make sure everything is ok. You may also ssh to it or simply open your browser and point it towards the vm. The webserver should be running if everything came up nicely.

Using the blimp

As the host comes up you can start to browse it's web-bages and register users for the different functionalities. Unfortunately, there is no common framework in order to add one user for all three services. That would be very nice, and suggestions are welcome. You can log into the blimp either through ssh or screen:

ssh root@

# or as the user owning the virtual machine: 

screen -r -d zeppelin

I root's home directory you will find a file called README.txt. It contains all admin usernames and passwords for all the services. It also contains some information about database and webserver setup.


User registration requires mails being sendt to the registrar. The blimp uses postfix as its mail server and it will try to deliver the email as best as possible. However, some sites require you to use a special mail relay in order to deliver the mail out from the site. For an additional tweaking of the mail setup, look at the file called /etc/postfix/


The performance of your vm is given based on what your physical machine is capable of. The above settings for the vm are reasonable, but you might be able to use even less resources. The webserver only accepts max 30 connections. It is reccomended to get the SKAS-patch for your host kernel. It enhances both security and performance.