These days, it isn't uncommon for even small businesses to maintain multiple Web sites. One site might be for sales and another for support, or business partners might have a site all to themselves. If you manage an intranet, the problems multiply. You might have different Web sites for each business unit, or even for each department.
As soon as you start adding new Web servers to your infrastructure, IT costs escalate. So even though each of your sites' needs may differ wildly, it probably doesn't make sense for each group or department to have its own dedicated Web server. For every server you install, someone has to be responsible for basic maintenance tasks. Most groups simply won't have the resources.
The traditional answer is to use virtual hosting and have a single machine serve several departments, with centralized administration. The problem is, many departments won't be satisfied with a place to dump simple Web pages. They'll probably want to run CGI scripts, set up periodic cron jobs, or even install new software on the server. Sure, you can open up CGI directories or use scripting languages like ASP or PHP, but security remains a concern. On a shared server, it only takes one careless user to expose everyone's sensitive data.
Another popular solution is to use a product like VMWare to create multiple virtual machines on one computer. This eliminates the expense of purchasing new hardware, but it doesn't solve the problem of infrastructure complexity. Virtual machines are completely independent of one another; they can even run different operating systems. Because of this, managing many sites is still a chore. Unless each server owner will handle all of the management responsibilities for his or her own virtual machine, you'll still wind up having to update and upgrade multiple servers (albeit virtual ones).
The Middle Ground
Fortunately, a relatively new kind of software can address this problem, provided you're willing to standardize on one operating system across all your sites. The idea is to deploy a single OS kernel on a single machine, but divide the kernel's system resources into multiple "lite" virtual servers, or sandboxes. Each sandbox runs its own Web server and email software, independent of the others. But although each virtual server has its own manager account, the superuser can make changes on all of the machines at once.
FreeVSD (www.freevsd.org) is one such system. Though aimed primarily at ISPs, it works well for other tasks as well—for instance, running development Web sites in parallel with production sites, or testing new software without affecting a live site.
Setting up FreeVSD is simple. The superuser prepares a prototype file system template, called a skel. (A number of prepackaged skels are available.) This template then becomes the basis for the file system of each virtual server. The superuser populates the skel with the files and software that the managers of the virtual servers will need to run their sites.
A FreeVSD virtual server is a chroot environment, meaning that any program running on the server sees the skel as the entire file system. No files or programs outside the skel are accessible. In addition, FreeVSD replaces several important commands. For example, the ps command only allows users to see the processes associated with the current virtual machine. Commands like su, cp, and mv have been updated to recognize that the local admin user is privileged.
The superuser retains ownership of systemwide software that shouldn't be tampered with—for instance, programs like ls and cat. Within the skel, these files are actually hard links to the original programs, which are stored elsewhere. In this way, a FreeVSD system's total resource consumption is greatly reduced because every instance of a skel shares most of its files with all the others. (The FreeVSD Web site claims 20MB per virtual server, even though each skel contains the equivalent of around 500MB of files.) This makes it simple for the superuser to prevent major system problems that a reckless administrator might cause.
A virtual server must have its own, independent copy of any files that its owner might want to change. This might include the Apache configuration files, log directories, mail configuration, or any other areas that will change from server to server. Though there might only be one physical copy of the MySQL application, for example, each virtual server can run an instance of the database configured for its exact needs. Usually, the owner of these configuration files is the local admin account, which acts as the virtual server's superuser.
Because all the common system files are really just hard links back to the master files, which are owned by root (and not the local administrator of any one virtual server), it's easy to upgrade the system. In addition, backing up the entire machine is simpler since you only need to back up those parts of each virtual server that differ from the others.
Network Considerations
Although FreeVSD sounds simple, there are a few issues of which you should be aware. Each virtual server has its own IP address and can answer network requests on the usual ports. However, applications running within a FreeVSD sandbox cannot run as root; they can only run as the admin user for that particular virtual machine. On most Unix systems, users other than root can't open privileged ports (that is, ports below 1024). Because a Web server usually listens on port 80, for example, this can pose a problem.
There are several ways around this. With modern Linux kernels (2.4.x and above), the superuser can use IPtables to route packets to a nonprivileged port. In a standard installation, the IPtables will direct each machine's port 80 to port 8080 and port 443 (the HTTPS port) to port 8443. Remember, each machine has its own IP address, so it's clear which machine should handle which incoming requests. And unlike methods used with older kernels, using IPtables allows server logs to correctly reflect incoming IP addresses. As long as the root user anticipates which ports the virtual machine should handle, this method works well.
A virtual machine's admin can also set bandwidth and disk space quotas for either the entire virtual server or individual users. The admin can configure Apache, so each virtual machine can host multiple Web sites. Usually, these will use name-based virtual hosting, although it is possible for one virtual machine to have multiple IP addresses.
Installing Software
The admin user for a virtual server can install any software he or she likes, assuming two conditions are met. First, the software can't conflict with items in the skel, which are owned by root. If a software package needs to alter some common directory over which the superuser has reserved control, not even the virtual server's administrative account will be able to install or run the software. The second condition, of course, is that the software can't require actual root access—for example, an application can't be hard-coded to run as root so that it can open ports below 1024.
Even with these restrictions, there is a wealth of practical software you can install into a skel. You can easily install nearly any kind of CGI program, log analysis, or utility software on a virtual server, and precompiled Apache modules work without complaint, too. The admin user even has access to gcc, so software that needs to be compiled from C or C++ source is no problem.
Admin users can log into their machines using telnet or (preferably) SSH. From the shell, you can do all the normal things you'd expect to do with a Unix server. In addition, FreeVSD has a Web interface for administration, and an administration client application that runs under Windows.
Rightsizing
Systems like FreeVSD are ideal for dividing a single server among several users or departments. Even if your users' needs aren't sophisticated enough to require multiple servers, partitioning each department into its own private sandbox can simplify administration considerably.
FreeVSD has several distinct benefits over a truly private server, or a rigidly virtualized server. In particular, FreeVSD requires fewer resources than does installing new hardware for each department, because every FreeVSD virtual server shares disk space and kernel resources. Perhaps more important, administration with FreeVSD is much simpler than having multiple computers, either real or virtual.
The downside, of course, is that you need a machine powerful enough to run several virtual servers at once. In addition, the virtual servers are not perfectly protected from each other. Because every virtual server is really just a collection of processes running on the same physical Unix server, one virtual server can potentially starve the others for resources. Still, for economy and ease of use, FreeVSD is a great answer when virtual hosting isn't enough, and a dedicated server is too much.
Al is the author of many popular programming books, including Java 2 Network Protocols Black Book (Coriolis). You can find him at www.al-williams.com.
