Go Beyond

Only read if you don't mind being offended.

vhost layout

A while back, I had a fairly interesting vhost setup in lighttpd. It looked like this.

[root@potatostew ~]# ls -l /srv/http/
total 32
drwxr-xr-x 11 root http 4096 May 30  2013 domains/
drwxr-x---  2 http http 4096 May 23  2009 fcgilair/
drwxr-x---  3 http http 4096 May 20  2013 htdocs/
drwxr-xr-x  2 root root 4096 Jun  3  2011 magnet/
drwxr-xr-x  3 root root 4096 May 23  2009 public/
drwxr-xr-x  2 root http 4096 May 30  2013 shared/
drwxr-xr-x  3 root root 4096 Jun 29  2009 sites/
drwxr-xr-x  6 root http 4096 May 30  2013 users/

lighttpd's simple vhosts pointed to domains. domains had symlinks to the users. fcgilair held sockets for fastCGI. Basically, each user could create as many domains as they wanted. They'd have to convince the server owner to make a symlink to them. sites were arbitrary and one-off, stuff not managed by users. shared, magnet, and public, I'm not sure off the top of my head. htdocs may have been leftover.

FastCGI processes ran as their own user and provided basic isolation that way. lighttpd configuration had a include_shell which ran a script that would iterate through users in a configuration file for who was allowed to have varying degrees of FastCGIness. Could have different variants of PHP, treyfcgi, or others. I guess ideally, this would be done by groups now.

The fcgispawner would make the children needed and set the permissions. The fcgiconfigmaker (invoked by the lighttpd config) would generate the lighttpd configuration necessary. A SIGHUP reload could add new users without breaking anything. There was no logic to sanely handle removing users and killing processes.

I've seen so many setups where people go in and manually make a vhost per site, even if they are all pretty much identical. This has much less maintenance overhead.

I think I had about 7 sites each running their own FastCGI PHPs (or maybe that was 7 users and there were more sites, as you can separate those with this model). Along with SMTP/POP3, SSH, FTP, and MySQL. This was on a 256MiB 64bit Arch Linux VPS. Performance was decent for what it was.

Ultimately, if you're doing vhosts, consider simple vhosting so it's mostly just filesystem-based management. Or better yet, make static content and push it to S3/CloudFront, or Cloud Files.