Paranoid Penguin - Running Network Services under User-Mode Linux, Part II
The procedure for building your own root filesystem image boils down to this:
Create an empty filesystem image file and mount it to some directory.
Install Linux into that directory.
Sounds simple, right? On Debian and SUSE it is—sort of. On other distributions, it's much less so. Regardless, I'm going to save a more-detailed discussion of that process for my next column, in which I'll cover what I consider to be advanced User-Mode Linux topics and techniques. In the interests of getting you up and running with User-Mode Linux in a gratifyingly quick manner, for now I recommend you download a prebuilt image.
My favorite source of these is Nagafix Ltd.'s “UML Resources” page (see the on-line Resources) from whence you can download root filesystem images for not only Debian guests, but also Gentoo, Slackware, Fedora, Ubuntu and others. Nagafix makes a reasonable effort to keep these images up to date with security patches, which is a nice touch.
In addition, Nagafix provides an MD5 and SHA hash of each image file it provides. You may miss them if you click directly on the x86 and AMD64 links on the page cited above; instead, use the OS-name links, each of which leads to a page containing links not only to images but also to build logs and hashes, plus handy tips on how to update the images yourself.
I obtained my Debian 3.1 image by navigating to uml.nagafix.co.uk, clicking on Debian 3.1, and then clicking on the root_fs and MD5 links to download the files Debian-3.1-x86-root_fs.bz2 and Debian-3.1-x86-root_fs.bz2.md5, respectively. After my downloads were complete (the filesystem image itself is 169MB!), I verified the MD5 signature from within a terminal window with the command:
md5sum -c ./Debian-3.1-x86-root_fs.bz2.md5
When in Doubt, Roll Your Own Image
Even if you use a root filesystem image from a trusted source and verify its integrity via an MD5, SHA or GPG hash/signature, the fact is, if you're truly worried about security (we are, aren't we?), you're much better off building your own filesystem image than using someone else's.
I'm indulging in just a little laziness and instant gratification by using a prebuilt image in this article, which I think is justifiable in the larger aim of encouraging UML experimentation and adoption. Just be sure to check your image's hash/signature, and the first time you mount it in UML, run apt-get dist-upgrade (or YaST Online Update, yum or whatever update mechanism your guest's distro supports).
Next time, I'll discuss the filesystem image build process in more depth, as well as how to use iptables both on your host and on your guest OSes to add another layer of protection to your virtual machines.
And, now we're ready to boot our virtual guest for the first time. We've got a guest kernel named uml-guestkernel-126.96.36.199 (from my previous column's example) and a root filesystem image named Debian-3.1-x86-root_fs.bz2. You should already be logged in to a terminal session as a nonroot user. Uncompress the filesystem image with the command:
Next, just as a sanity check, try booting your guest system:
umluser@host:~> ./uml-guestkernel-188.8.131.52 ↪ubd0=testcow,Debian-3.1-x86-root_fs root=/dev/ubda
If all is well, you should see some User-Mode Linux messages, followed by a longer string of Linux kernel startup messages, ending with a login prompt. Log in as root—you won't be prompted for a password. Feel free to poke around a bit; you won't hurt anything that can't be fixed later by starting with a fresh COW file.
To see a list of installed packages, enter the command dpkg -l |less. You may be surprised by how few Debian packages are present. Don't worry; you'll be able to install additional packets with apt-get, just like on a “real” Debian system. When you're done with your initial exploration, issue the command halt to shut down your guest system cleanly. We've got some things to do before your guest system can do any serious work—first and foremost is configuring networking.
There are a variety of ways to network UML guests, all of which are described in Rusty Russell's User-Mode Linux HOWTO (see Resources). The best option for using UML guests as network servers is bridging, in which your host system acts like an Ethernet bridge between itself, the UML guests running on it and the outside world.
In a nutshell, the procedure is this:
Configure your host's TCP/IP stack as a virtual bridge, and then define your “real” network interface as the first “port” on that bridge.
For each guest system you intend to run, create a local tunnel interface and define it as another port on the bridge.
When you start a guest system, define its virtual Ethernet interface (eth0) to be the tunnel interface you created in the previous step.
Listing 1 shows the precise series of commands this translates to, adapted from David Cannings' useful article “Networking UML Using Bridging”. All these commands must be executed as root.
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
|Firefox Security Exploit Targets Linux Users and Web Developers||Aug 17, 2015|
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- My Network Go-Bag
- Firefox Security Exploit Targets Linux Users and Web Developers
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- diff -u: What's New in Kernel Development
- August 2015 Issue of Linux Journal: Programming