Based on the Virtual Services HOWTO (Brian Ackerman), Virtfs will make hosting virtual servers in an organized and relatively easy fashion. With this Perl script, you will be able to add and delete virtual servers, as well as set up the virtual servers for Apache, FTP, and E-mail. In addition, typical system administration tasks can be carried out, such as adding/removing users and groups, and simple Sendmail configuration.
Please have Ackerman's Virtual Services HOWTO handy as you read this document. Hopefully this document will explain everything to get you up and running with Virtfs.
If you are thinking of setting up one or two small virtual servers, then Virtfs is probably not for you: whilst using Sendmail's virtual email support (and the such), you should be fine. However, if you will be setting up many virtual servers (ie. an ISP setting up a virtual server for each of their clients), you may want to use Virtfs. That is, if your clients want a dedicated filesystem. For example, they would like a system with their own passwd file (so they can add/remove users themselves), or when they log in to their virtual server, no other client has access to their filesystem - as all virtual servers are hidden from one another. Each server can have different users and groups from one another.
However, if you are thinking of running a few virtual servers which do not require special customization, and will handle a few users, you may want to look at the Pocket ISP based on RedHat Linux HOWTO (written by Anton Chuvakin).
There are quite a few methods used for virtual servers, however Virtfs takes advantage of the system's chroot features. What chroot does is set any given directory on your filesystem to a root directory. For example, chroot can set /home/user to the / directory (although if you try it now, it may not work complaining that a shell could not be found).
By copying the main files (and directory structure) from the main server to a specific location, we create a template of what each virtual server consists of. Then, for each virtual server you want to create, we link them to the template that we created. This saves drive space as well as organizing everything.
But how does the process of Virtual Servers actually occur? If we create a virtual server (say, vserver.com) in the directory, /virtual/vserver.com, we chroot to /virtual/vserver.com and everything is set up as a virtual server. Upon executing chroot on /virtual/vserver.com, the /etc directory will in fact be /virtual/vserver.com/etc and not /etc (as we know it on the main server). So, if a client edited vserver's /etc/passwd file, it will in no way be affecting the main server's passwd file. The client will be editing their /etc/passwd file but in reality they are editing /virtual/vserver.com/etc/passwd. To them, when they are editing /etc/passwd, they are actually editing /virtual/vserver.com/etc/passwd on the main server.
In addition to this, once you are within a virtual server, you cannot see the files belonging to the main server. Therefore a client would not be able to see another client's filesystem, or even the main server. To them, their virtual server is their "main" server, and they cannot see beyond that.
Services (ie. FTP, E-mail, Samba, etc..) for each virtual system will run individually from one another, and even from the main system.
When you FTP into a server, how does it differentiate which virtual directory to chroot to? This is done by a small wrapper (written in C) that informs your services (usually set up in /etc/inetd.conf) where to start. Tha name of this nifty program is virtuald. Basically virtuald reads in a configuration file and matches the IP address of a server called upon to the directory where the files reside. Virtuald then hands this information off to the service, and the service carries on as usual.
For example, you set up a virtual server, vserver1.com, and vserver2.com. In your configuration file you map out the IP address for each of these servers, to point to their proper location on your main server (/virtual/vserver1.com and /virtual/vserver2.com). You configure your inetd to run a specific service through virtuald, say FTP.
When a user FTP's to vserver2.com, virtuald will lookup the directory for the certain server, and chroot to it, setting /virtual/vserver2.com to make it seem like the root (/) directory to the user. The FTP service will then know where to start. If no matching IP address is found, the service runs through as normal logging into the main server. For each service there should be a different configuration file.
Don't worry about the configuration files, as Virtfs automatically adds or deletes the entries within it as needed. Virtuald is contained within the Virtfs package.
One of the main advantages on seperating your virtual servers this method, is control. You, the system administrator, has total control of each filesystem.
Another advantage is the flexibility of running different services for different servers. As in the above example, we could have easily shut off FTP service for vserver2.com but kept it on for vserver1.com. Also, a user at vserver2.com, say bob@vserver2.com is not the same as bob@vserver.com, or even bob@mainserver.com (Sendmail will not get confused as virtuald will sort everything out, prior to Sendmail kicking in). This method causes the main server not to be cluttered up with your client's email accounts. They will be all contained within their own directory.
A big disadvantage is disk space. Creating many filesystems can get expensive, but there are some ways to combat this. If users on a virtual server do not need X-Windows, don't copy it over (and files supporting it). If users do not need Emacs, don't copy it over, and so on. For each virtual server, you can pick and choose what should reside on it. Just as long as the important base system (in addition to what services each virtual server needs) exists it should be fine.
You can hard link binaries from the main server to your virtual servers, that need to be used. When I create virtual servers, they usually take up about 10-15 MB.