This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Enterprise Applications

Installing Linux-VServer

By Marc Abramowitz on January 08, 2007 (8:00:00 AM)

Share    Print    Comments   

Linux-VServer offers a simple way to run several virtual servers on one piece of physical hardware. While it lacks some of the flexibility of more complex virtualization schemes, it is simple to implement and is capable of excellent performance.

Linux-VServer, and similar software like OpenVZ, take a "lightweight" approach to virtualization, essentially segmenting a single Linux kernel environment into virtual machines with separate file systems, process tables, and network addresses.

This is sometimes referred to as a "jail" approach, because it closely resembles a feature called "jails" that is pretty well-known for the FreeBSD operating system. FreeBSD jails are, in turn, an extension of the chroot jail concept, which has long been supported by many UNIX kernels, including the Linux kernel.

Paravirtualization vs. full virtualization

When many people think of virtualization, they think about full virtualization software that emulates a virtual machine all the way down to the hardware level and lets an operating system run on top of that emulated hardware. This is the approach taken by several well-known software packages such as VMware, QEMU, and Bochs.

Full virtualization software does extensive virtualization of hardware, including the processor, BIOS, and I/O devices. One of the advantages of this approach is that just about any operating system can be run on the virtual hardware. One disadvantage is that emulating down to the hardware layer involves a lot of overhead, which usually results in a noticeable performance degradation for the guest and host operating system.

Recent years have seen a lot of interest in another virtualization technique called paravirtualization. With paravirtualization, virtual machines run inside a virtual machine monitor (VMM), or hypervisor, and access its services through a software interface.

Paravirtualization is actually an old technique dating back to IBM mainframes, but lately it's increasingly being applied to personal computers with software such as Parallels Workstation and Xen. Paravirtualization does have drawbacks, though, as it typically requires either the guest operating system to be modified to support the hypervisor, or specific hardware support in newer Intel and AMD processors.

If you're willing to constrain your choice of guest operating system to Linux, then you have other options, such as User-mode Linux (UML) and Linux-VServer, which virtualize at a higher level, resulting in increased performance. UML allows a Linux kernel to run as a user process (like any other Linux process, such as Emacs or Vim) within a "host" Linux operating system.

This interesting technology has a number of advantages, such as the ability to run any recent UML-enabled kernel of choice (including one different from the kernel of the host system) and the ability to debug the kernel of the guest system more easily.

If you're familiar with the chroot system call, then you know that it changes a process's root directory to some subtree of the larger file system. This technique is commonly used to improve computer security by placing a vulnerable server process in a chroot jail that is isolated from the rest of the system. For example, you can configure the popular BIND DNS server to run in a chroot jail such as /chroot/named.

Within this chroot jail, /etc/passwd, for example, would map to /chroot/named/etc/passwd in the main file system. The benefit is that even if an intruder manages to find an exploit in BIND that gives the intruder the ability to run code as root, the attacker cannot affect files outside of /chroot/named. The chroot jail concept can be considered to be a limited form of virtualization. While chroot jails provide processes with completely isolated file systems, other aspects of the system are not isolated. For example, within a chroot jail, all the processes of the host system are visible, and network addresses are shared with the host system.

FreeBSD's jails and Linux-VServer take the chroot jail concept further, making sure that virtual machines have separate process tables, resource limits, terminals, and network addresses. Note that this is a lightweight form of virtualization, as no emulation of hardware is occurring.

As a result, the virtual machines, often called security contexts or Virtual Private Servers (VPS) in Linux-VServer parlance, can run at nearly the full speed of the underlying physical hardware. Unlike some other virtualization approaches, all the virtual servers run under the control of the same kernel. This minor limitation is often outweighed by the increase in performance that you can achieve by running a single kernel. Also keep in mind that although you're limited to a single kernel for all your virtual machines, there is no problem with running different Linux distributions in your virtual machines (as long as those Linux distributions can work with the chosen kernel).

Linux-VServer is composed of two parts: Code in the kernel to support security contexts, and userspace tools for creating and managing virtual servers.

The userspace tools are typically easily installed with the package management system of your distro. As for the kernel, you must run a kernel that has support for VServer security contexts. You can either download a kernel built with this support, or you can download a VServer patch that you can apply to your kernel source code before building.

Installing Linux-VServer

This is how I set up Linux-VServer on my Ubuntu 6.10 (Edgy Eft) system. This should work with little or no modification on Debian and Debian-based distros, such as Knoppix, Xandros, and newer versions of MEPIS. If you're using another distro, then you can probably follow the same basic approach, but you may need to use different packages.

First, I downloaded a pre-built VServer-patched kernel. If you'd rather build your own kernel, then you can download a VServer patch instead that you can apply to your kernel sources before building a custom kernel with make-kpkg or the like.

In the case of Ubuntu, the VServer patch is available as a package called kernel-patch-vserver. For more information on compiling a custom Ubuntu kernel, check out the Ubuntu Wiki KernelCustomBuild page.

Next, I installed the kernel using dpkg:

sudo dpkg -i linux-image-2.6.15-27-686_2.6.15-27.45vs2.0.1+2.0.2rc26_i386.deb

After that was installed, I rebooted to load the new VServer-enabled kernel.

The next step is to install some VServer utilities that would make it possible to create and manage VServer instances:

sudo apt-get install util-vserver vserver-debiantools debootstrap

That's it. Linux-VServer is installed! Now I'll show how I created a virtual server that runs the 6.06 LTS (Dapper Drake) version of Ubuntu.

Building a virtual server

Building a virtual server is pretty easy, and is done using the vserver command:

vserver vserver1 build -n vserver1 --hostname vserver1.mydomain.com --interface eth0:192.168.1.31/24 -m debootstrap -- -d dapper

This command builds a virtual server called "vserver1" with the hostname vserver1.mydomain.com and a virtual Ethernet device with an IP address of 192.168.1.31 that resides in the 192.168.1 network with a CIDR prefix length of 24.

This virtual server's package database and file system are populated by a command called debootstrap (from the package of the same name), which is passed the argument dapper so that it retrieves packages from the Ubuntu Dapper Drake package repositories.

Since this step involves downloading and installing a number of packages, it takes a while but not as long as installing the full-fledged distro, because debootstrap only downloads and installs a minimal set of packages to get you going. You can install more packages later. Note that debootstrap is specifically for bootstrapping Debian-based systems.

If you're installing another type of distro, then you'll need another tool. You should look at rpmstrap if you're installing an RPM-based distro.

The next step is to start the newly built virtual server and then enter it:

vserver vserver1 start
vserver vserver1 enter

Note that you're now in the virtual server (you could type exit to get out) and that you have a minimal set of packages installed. If you type top, you'll see very few processes running on your virtual server. And df will show that your root filesystem is coming from a virtual block device, probably with a name like /dev/hdv1.

Further configuration

At this point, you have a pretty basic virtual server. It is likely that you'll want to install additional packages and add users to the system. The method for doing this is no different from the method you'd normally use on the host system. Here's one simple and useful example:

apt-get install ssh

adduser marc

Now you can ssh to your virtual machine. It would be just as easy to install Apache or BIND or an SMTP server. You could even build separate virtual servers for each of your server processes, such as Apache, BIND, and an SMTP server.

In fact, this is a pretty good idea from a security standpoint, as it isolates each of these processes from one another and prevents a compromise of one from affecting the others (obviously a power outage or a hardware failure will kill all these processes, since they're still running on the same physical hardware).

Alternatively, if you want to try out the latest versions of Debian and Gentoo, you could install them both in separate virtual machines. Or you could install all new experimental software and upgrades in a separate virtual machine first, so there's no chance of it breaking your system. As you can see, there are many uses for virtualization.

Conclusion

Linux-VServer allows you to create lightweight virtual machines with little overhead and great performance, while still providing increased security and fault isolation. You can use it to create a secure and fault-tolerant system without investing in additional hardware. You could also use it to mimic other development environments or to try out the latest Linux distro without having to buy another machine and without having to worry about it wrecking your system.

Share    Print    Comments   

Comments

on Installing Linux-VServer

Note: Comments are owned by the poster. We are not responsible for their content.

Are you limited to only one OS?

Posted by: Anonymous Coward on January 09, 2007 11:49 PM
Can I run Ubuntu as the host, Centos as a client?

I like the idea of running in a chroot jail, but it won't be much use if I'm limited to one OS

#

Re:Are you limited to only one OS?

Posted by: Administrator on January 10, 2007 02:12 AM
I believe the only common thing between the guest machines is the Kernel itself. I think you can run any Linux distribution that runs on it in the guests.

If you are not too fussy which kernel you run with your distros and they are all more or less compatible (which is the case for most) then the answer is yes.

Someone is sure to correct me if i am wrong....

#

Re:chroot "jail" can be escaped by root

Posted by: Anonymous Coward on January 11, 2007 04:56 PM
That trick won't work with vserver, it uses barrier-checking for 2.4.x, and namespaces in 2.6.x.
Vserver is secure with regards to breaking chroot barrier.

#

Re:chroot "jail" can be escaped by root

Posted by: Administrator on January 12, 2007 06:11 AM
Again - read the subject - I was talking about "chroot" only.
That's why I'd expect Vserver to be more secure than a chroot jail, which really doesn't add much security.

#

chroot "jail" can be escaped by root

Posted by: Administrator on January 10, 2007 06:49 AM
Hi,

The notion that nobody "escape" a chroot'ed enviconment (i.e. access files outside the chroot directory) is false - if a root process inside a chroot environment does "mkdir x; chroot x" then "multiple chdir<nobr> <wbr></nobr>.." it will eventually get out of the jail.

I use shell syntax above but actually you need to do all this in one process so you'll need a statically compiled executable to test this.

This happens because the "chroot x" will change the process's root to a directory which is actually under its CURRENT directory, and since all the "chdir<nobr> <wbr></nobr>.." syscalls after that will not encounter the process's chroot they will succeed all the way up to the real root. All that is left then is to "chroot<nobr> <wbr></nobr>." and run a shell.

I though I should point this out because you say in paragraph 5 (with the BIND break-in example) that a chroot'ed BIND process will save the day from a root exploit in the BIND program.

Besides that - great article and thanks very much for putting it up.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya