Ted -- You asked about, if I read you correctly, how to protect your host and your other clients from a site being hacked. I'll say up front that I'm very much not a fan of virtual machines simply for partitioning and segregation because I *way* do not want to mess with the overhead of managine multiple OS instances; care and feeding of one is work enough without expanding by an order of magnitude. I also am not a fan of jails for the average user or process because, again, it takes work to maintain such a structure. My suggestion is to ensure that each client has - its own IP - its own user(s) - its own process(es) - its own directory tree with which to operate, thus isolating each from the other. If Customer X on IP a.b.c.X running httpd as user X in /path/to/X gets hacked (or even decides to go looking around), only content under /path/to/X is exposed and only the X httpd is compromised. Customer Y, on IP a.b.c.Y running httpd as user Y in /path/to/Y, is completely safe. You'll need to ensure that each directory tree is limited to only the relevant user & group to prevent others from wandering around via ssh, sftp, ftp or a site hack. Meanwhile, if Customer Y has a bug and locks up his httpd, Customer X is remains up & running. The best practice is to install a complete and independent copy of any application software (httpd, JRE, perl, ...) so that Customer X can configure however he wants and differently from how Customer Y does it; disk space is cheap and then you don't have to worry about conflicting modules or versions, but YMMV. Of course, all of this depends on having an IP or at least a port for each customer -- but, then again, so does the VM approach, plus with a firewall you can easily NAT & redirect traffic on your single public IP if that's your preference. As an added bonus, I not only run httpd as a distinct user but in fact as a "sub account" of the customer so that the running process only has the ability to change log files and such. Thus, Customer X has an X account which can create/maintain/destroy content & configuration files (HTML pages, JPGs, PHP code, etcetc) *and* is also a member of group "Xn", which is the primary group of a separate account Xn, which is what runs the httpd process and only has write access to log directories. Now, if the site is hacked, the worst someone can do to the local content is ... modify a log file; there's no changing of HTML pages or dropping of malware or other such. [That doesn't say, of course, that the bad guy can't also mess up the data in the DB or launch other attacks or whatnot; all of that is common to your code development no matter what account is running the web server process.] By isolating, separating, and containing each customer in this way you get very effective control and security at a very low price. Adding a new customer is as simple as making an account or two, setting up a home directory tree, and perhaps providing the standard package installs that you offer. In my corporate life, we've been doing this for about 8 years now, with a few hundred thousand web, middleware, and database "vtiers" (virtualized instances of a service tier) across about 40k servers, and we easily meet SOX, PCI, and similar control requirements. In my personal life, I even do this at home when setting up both local persistent services (samba, httpd, ...) and working on my own PHP development. Enjoy :-) HTH & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt