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-2.6.17.3 (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:
bunzip2 ./Debian-3.1-x86-root_fs.bz2
Next, just as a sanity check, try booting your guest system:
umluser@host:~> ./uml-guestkernel-2.6.17.3 ↪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.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Reply to comment | Linux Journal
3 min 18 sec ago - Reply to comment | Linux Journal
6 hours 57 min ago - Reply to comment | Linux Journal
7 hours 13 min ago - Favorite (and easily brute-forced) pw's
9 hours 4 min ago - Have you tried Boxen? It's a
14 hours 56 min ago - seo services in india
19 hours 28 min ago - For KDE install kio-mtp
19 hours 28 min ago - Evernote is much more...
21 hours 29 min ago - Reply to comment | Linux Journal
1 day 6 hours ago - Dynamic DNS
1 day 6 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
When is better to use chroot than UML
I am interested to know when would actually be worth to use uml than chroot in the case of running a single service. For example, I would like to run an IRC or a web server. Which approach would be better when you consider separately one of this factors:
-Configuration effort.
-Resources used (RAM, Hard Disk)
-Security
Any comment would be truly appreciated.
Alvaro