|
|
The MLN ProjectComplex virtual machine management made easy |
Navigation |
The Blimp: Using MLN to set up a information centralIt 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:
We assume you have a Linux box running Debian Linux. You can use other distros too, off course. Preparation
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: http://user-mode-linux.sourceforge.net/skas.html A more recent (but unofficial?) repository can be found here: http://www.user-mode-linux.org/~blaisorblade/ Setting up MLNIn 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" >> ~/.mlnNotice 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 lEmXSNb8apZVQ Initial Decision: NetworkingBefore 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 bridgeUsing 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-globalNote 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 = 128.39.89.10
$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
address 10.0.0.15
netmask 255.255.255.0
broadcast 10.0.0.255
gateway 10.0.0.1
}
Alternative 2: A Tuntap deviceWith 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: 10.0.0.15 # tun0-address: 10.0.0.14 root:# tunctl -d tun0 -u kyrre Set 'tun0' persistent and owned by uid 1000 root:# ifconfig 10.0.0.14 netmask 255.255.255.0 up root:# chmod 666 /dev/net/tun root:# route add -host 10.0.0.15 dev tun0 root:# arp -Ds 10.0.0.15 eth0 pubAgain, 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
tun_address 10.0.0.14
address 10.0.0.15
netmask 255.255.255.0
gateway 10.0.0.1
}
startup {
route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.14
}
Building and startingBefore 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.mlnIf you recognize the configuration and want to proceed to build, remove the "-s" option. mln build -f blimp.mlnThe 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 blimpYou 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 blimpAs 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@10.0.0.15 # or as the user owning the virtual machine: screen -r -d zeppelinI 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. PerformanceThe 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. |