Running Network Services under User-Mode Linux, Part I
Okay, we've got UML host capabilities, but we still need a guest kernel to run. This process is somewhat simpler than the host-kernel build, because we don't need the skas patch.
First, navigate back to the directory in which your Linux kernel-source tarball resides, and unpack it a second time. Remember when we renamed the unzipped source code directory? This was so we could unpack the kernel tarball a second time. We need to build our host and guest kernels in separate source trees.
On my Debian test system, therefore, I unpacked the source tarball to /usr/src/linux-220.127.116.11, and this time, renamed it to /usr/src/linux-18.104.22.168-guest. Again, change ownership of this directory to a nonprivileged user, and change your working directory to it.
Again, at this point we can skip the step of applying the skas patch. Because we're going to compile our kernel for the special um (User-Mode Linux) architecture rather than for a real architecture like x86, I recommend you prepare your source code tree with the following three commands:
host:/usr/src/linux-22.214.171.124-guest$ make mrproper ARCH=um host:/usr/src/linux-126.96.36.199-guest$ make defconfig ARCH=um host:/usr/src/linux-188.8.131.52-guest$ make menuconfig ARCH=um
The make mrproper command clears out any configuration and object files in your source tree; make defconfig generates a fresh default configuration file appropriate to the um architecture; and make menuconfig, of course, gives you the opportunity to fine-tune this configuration file.
Pay particular attention to the following:
Life will be simpler if you skip loadable kernel module support and hard-compile everything into the kernel. If you really want kernel modules, see the User-Mode Linux HOWTO, Section 2.2 (see Resources).
Under Processor type and features, double-check that your system architecture is set to um (User-Mode Linux), and make sure /proc/mm is enabled.
Under Networking options, make sure IP: tunneling and 802.1d Ethernet Bridging are enabled.
Under Network device support, enable Universal TUN/TAP device driver support.
Disable as many of the specialized hardware kernel modules as possible; this kernel is going to be running on virtualized hardware, so you won't need support for wireless LAN hardware, obscure parallel-port devices and so forth.
Once you've saved your new configuration file, you can compile the kernel with this command (without first becoming root; execute this as an unprivileged user):
host:/usr/src/linux-184.108.40.206-guest$ make linux ARCH=um
Note that I did not tell you to make a zipped or bzipped image. Remember, you're going to be running this kernel as though it were a user-space command, so it shouldn't be compressed. The finished kernel will be located in the top-level directory of your source tree (/usr/src/linux-220.127.116.11-guest in the above examples) and will be named linux—you'll probably want to rename it to something more descriptive, such as uml-guestkernel-18.104.22.168. You'll also probably want to move it to the directory from which you intend to run it—perhaps something like /usr/local/uml/.
By the way, don't be scared by the size of your guest kernel file. Most of that bulk is symbol information that will not be loaded into memory when you execute it.
Your host system now fully supports User-Mode Linux, and you've got a guest kernel image to run. The next step is to obtain or create a root filesystem image to use with the guest kernel. That's where we'll pick up again next time!
Resources for this article: /article/9260.
Mick Bauer (email@example.com) is Network Security Architect for one of the US's largest banks. He is the author of the O'Reilly book Linux Server Security, 2nd edition (formerly called Building Secure Servers With Linux), an occasional presenter at information security conferences and composer of the “Network Engineering Polka”.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script