Setting up a Low End Virtual Private Server 1/3

A VPS is basically a slice of a normal server, so you rent a bit of a full server with the size of that bit dependent on how much you are willing to pay. You get your own full OS installation (which is usually Linux for the cheap VPSs) and you can do anything with them that you like. You can get VPSs up to half the size of a normal server but they cost more than I earn in a year, so realistically I'm in the £5 a month category which doesn't buy you much. With a decent amount of tuning though you would be surprised what you can achieve, and of course you can easily convert your VPS upwards or downwards according to demand.

1. Find a decent VPS provider

This is very easy: go to Low End Box and read through the reviews. Overwhelmingly the US based VPSs are cheapest, then Germany, then the UK - however, remember that you will be spending most of your time in a SSH session so ping times are important unless you like long lags between keypresses. You also get a choice between OpenVZ and Zen - OpenVZ can be better if the sysadmin is competent and doesn't oversell the box, whereas Xen is less performant but much more predictable.

I went with buying a full year in advance from cheapvps.co.uk which is the unmanaged arm of the respectable VAServ VPS hosting company. If you buy a full year at once, they will double your VPS spec which meant that I got a UK-based Xen-based 256Mb RAM, 20Gb HD and 300Gb of bandwidth VPS for just £4.75 a month (US$9). It being UK based got me 65ms ping times from Ireland which makes typing much easier, plus I chose Ubuntu server for its OS. With cheapvps.co.uk you actually can choose between OS installations any time you like and there is quite a long list of alternatives including Windows Server 2003.

I personally would recommend with hindsight that you need a minimum of 256Mb of RAM unless you are willing to run really ancient server software and/or you don't mind a sluggish web service. As you will see later on, I aim for 128Mb to be in use at any given time with a maximum of 192Mb in burst - this leaves 64-128Mb for caching disc access which you really want if you can, and remember that there will be a spike in memory usage every time a SSL connection is formed. If you approach your RAM slice then your VPS will start swapping and things will slow right down. However, if you can only afford 128Mb of RAM, then my following instructions will at least get you a working server.

[Added Summer 2009: If you need something with 1Gb of RAM or more, low end fully dedicated servers are finally becoming affordable - you can get one from €30/month. See page three of this guide]

By the end of this, you should have a web server capable of running any PHP and MySQL based CMS, plus the email service will have excellent spam filtering.

2. Free up RAM

For some strange reason most VPSs will preinstall a 64 bit Linux OS. If you possibly possibly can, switch this to a 32 bit installation as 32 bit binaries are significantly smaller and use less memory during use. Chances are that your VPS will have no shortage of bandwidth, CPU nor disk space - its single & biggest bottleneck will be RAM. Even if you get your server running smoothly close to its RAM limit, wait till your first DDoS or bot attack and watch those memory spikes!

You can replace openssh with dropbear to save a few Mb of memory - it does no harm and it's not like you need the full openssh. Simply apt-get install dropbear and apt-get remove ssh and then apt-get autoremove to clean up. Also, disable a lot of the default tty processes which hang around eating up half a megabyte each - simply rename /etc/event.d/ttyX to something like /etc/ttyX.off.

Don't forget to add universe and hardy-proposed to /etc/apt/sources.lst and do an upgrade. If you're really short of RAM, replace bash with dash or even busybox though you may get shell script incompatibilities. I didn't bother with the latter two and ended up with the following memory free & processes:

top - 21:41:50 up 1 min, 1 user, load average: 0.69, 0.33, 0.12
Tasks: 32 total, 2 running, 30 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 262144k total, 41616k used, 220528k free, 2096k buffers
Swap: 0k total, 0k used, 0k free, 9728k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
971 root   15  0 2688 1536 1216 S 0.0 0.6 0:00.00 bash
970 root   15  0 2272 1204  784 R 0.0 0.5 0:00.08 dropbear
929 klog   24  0 2164 1132  400 S 0.0 0.4 0:00.01 klogd
984 root   15  0 2148 1032  828 R 0.0 0.4 0:00.00 top
  1 root   17  0 1880  964  524 S 0.0 0.4 0:01.61 init
906 syslog 16  0 1776  632  496 S 0.0 0.2 0:00.00 syslogd
358 root   12 -4 2064  628  364 S 0.0 0.2 0:00.00 udevd
927 root   18  0 1708  516  420 S 0.0 0.2 0:00.01 dd
967 root   18  0 1556  508  436 S 0.0 0.2 0:00.00 getty
869 root   16  0 1556  504  436 S 0.0 0.2 0:00.00 getty
966 root   18  0 1552  504  436 S 0.0 0.2 0:00.00 getty
941 root   18  0 1960  468  364 S 0.0 0.2 0:00.00 dropbear

29,792Kb (~30Mb) used is pretty damn good for Ubuntu v8.04 I think :)

3. Replace root

Firstly, create your own user account (preferably with a random bit on the end: the technical name for this technique is salting) and add it either to /etc/sudoers or the admin group. Check that it logs in and that you can sudo as root. Now disable root login in dropbear by adding the -w switch to /etc/default/dropbear extra args.

You probably should install ssh keys and disable password logins, but to be honest I have a long randomised alphanumeric password which is good enough in my opinion.

4. Install MySQL + Lighttpd + PHP

Apache is fine for big fast servers but it sucks for small ones. You must use Lighttpd instead which uses threads instead of forks to handle concurrent connections. You should also disable InnoDB from MySQL BEFORE doing anything else as that will save 100Mb of RAM. You can find RAM tuning guides all over the internet, but basically I ran lighty-enable-mod fastcgi and then I edited /etc/lighttpd/conf-enabled/10-fastcgi.conf:

"max-procs" => 1,
"PHP_FCGI_CHILDREN" => "4"

4. Secure ALL admin parts of the site

You don't want to get hacked, so you will need to be paranoid about security - particularly when you are installing, configuring and/or playing around with your website. PHP based admin tools such as phpmyadmin are very convenient but are deadly if they get broken into - you don't even want squirrelmail broken in reality.

To ensure full security, put auth digest (not the older auth plain) password blocks around every sensitive area of the website - this requires a user name and password to access. You should also always password protect an entire site if it may be in anyway vulnerable. Also, force the use of HTTPS for all the same sensitive regions - you don't want your emails nor your SQL transactions being readable if you use them to add passwords etc.

It took me a long time to figure out the lighttpd.conf to make these work, so here's mine for reference:

# Debian lighttpd configuration file
# 

############ Options you really have to take care of ####################

## modules to load
# mod_access, mod_accesslog and mod_alias are loaded by default
# all other module should only be loaded if neccesary
# - saves some time
# - saves memory

server.modules              = ( 
            "mod_access",
            "mod_alias",
            "mod_accesslog",
            "mod_compress",
            "mod_evhost",
            "mod_redirect", 
#           "mod_rewrite", 
#           "mod_status", 
#           "mod_evhost",
#           "mod_usertrack",
#           "mod_rrdtool",
#           "mod_webdav",
#           "mod_expire",
#           "mod_flv_streaming",
#           "mod_evasive"
 )

## a static document-root, for virtual-hosting take look at the 
## server.virtual-* options
server.document-root       = "/var/www/default/html"

## where to send error-messages to
server.errorlog            = "/var/log/lighttpd/error.log"

## files to check for if .../ is requested
index-file.names           = ( "index.php", "index.html",
                               "index.htm", "default.htm",
                               "index.lighttpd.html" )


## Use the "Content-Type" extended attribute to obtain mime type if possible
# mimetype.use-xattr = "enable"

#### accesslog module
accesslog.filename         = "/var/log/lighttpd/access.log"

## deny access the file-extensions
#
# ~    is for backupfiles from vi, emacs, joe, ...
# .inc is often used for code includes which should in general not be part
#      of the document-root
url.access-deny            = ( "~", ".inc" )

##
# which extensions should not be handle via static-file transfer
#
# .php, .pl, .fcgi are most often handled by mod_fastcgi or mod_cgi
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

 
######### Options that are good to be but not neccesary to be changed #######

## bind to port (default: 80)
# server.port               = 81

## bind to localhost only (default: all interfaces)
## server.bind                = "localhost"

## error-handler for status 404
#server.error-handler-404  = "/error-handler.html"
#server.error-handler-404  = "/error-handler.php"
server.error-handler-404 = "/error404.html"

## to help the rc.scripts
server.pid-file            = "/var/run/lighttpd.pid"

## 
## Format: <errorfile-prefix><status>.html
## -> ..../status-404.html for 'File not found'
#server.errorfile-prefix    = "/var/www/"

## virtual directory listings
dir-listing.encoding        = "utf-8"
server.dir-listing          = "enable"

## send unhandled HTTP-header headers to error-log
#debug.dump-unknown-headers  = "enable"

### only root can use these options
#
# chroot() to directory (default: no chroot() )
#server.chroot            = "/"

## change uid to <uid> (default: don't care)
server.username            = "www-data"

## change uid to <uid> (default: don't care)
server.groupname           = "www-data"

#### compress module
compress.cache-dir          = "/var/cache/lighttpd/compress/"
compress.filetype           = ("text/plain", "text/html", "application/x-javascript", "text/css")

#### status module
# status.status-url = "/server-status"
# status.config-url = "/server-config"

#### url handling modules (rewrite, redirect, access)
# url.rewrite                 = ( "^/$"             => "/server-status" )
# url.redirect                = ( "^/wishlist/(.+)" => "http://www.123.org/$1" )

#
# define a pattern for the host url finding
# %% => % sign
# %0 => domain name + tld
# %1 => tld
# %2 => domain name without tld
# %3 => subdomain 1 name
# %4 => subdomain 2 name
#
# evhost.path-pattern = "/home/storage/dev/www/%3/htdocs/"
evhost.path-pattern = "/var/www/%0/html/"

#### expire module
# expire.url                  = ( "/buggy/" => "access 2 hours", "/asdhas/" => "access plus 1 seconds 2 minutes")

#### rrdtool
# rrdtool.binary = "/usr/bin/rrdtool"
# rrdtool.db-name = "/var/www/lighttpd.rrd"


#### variable usage:
## variable name without "." is auto prefixed by "var." and becomes "var.bar"
#bar = 1
#var.mystring = "foo"

## integer add
#bar += 1
## string concat, with integer cast as string, result: "www.foo1.com"
#server.name = "www." + mystring + var.bar + ".com"
## array merge
#index-file.names = (foo + ".php") + index-file.names
#index-file.names += (foo + ".php")


#### external configuration files
## mimetype mapping
include_shell "/usr/share/lighttpd/create-mime.assign.pl"

## load enabled configuration files, 
## read /etc/lighttpd/conf-available/README first
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

#### handle Debian Policy Manual, Section 11.5. urls
### by default allow them only from localhost
### (This must come last due to #445459)
$HTTP["remoteip"] == "127.0.0.1" {
	alias.url += (
		"/doc/" => "/usr/share/doc/",
		"/images/" => "/usr/share/images/"
	)
	$HTTP["url"] =~ "^/doc/|^/images/" {
		dir-listing.activate = "enable"
	}
}

# Enable SSL
$SERVER["socket"] == ":443" {
  ssl.engine = "enable"
  ssl.pemfile = "/etc/lighttpd/ssl/vps.nedprod.com/server.pem"
  #ssl.ca-file = "/etc/lighttpd/theos.in/CA_issuing.crt"
}
# Force SSL on vps.nedprod.com
$SERVER["socket"] == ":80" {
  $HTTP["host"] =~ "vps\.nedprod\.com" {
    url.redirect = ( "^/(.*)" => "https://vps.nedprod.com/$1" )
    server.name = "vps.nedprod.com"
  }
}
# Force phpmyadmin to vps
$HTTP["url"] =~ "/phpmyadmin/" {
  $HTTP["host"] !~ "vps.nedprod.com" {
    url.redirect = ( "^/(.*)" => "https://vps.nedprod.com/phpmyadmin/")
    server.name = "vps.nedprod.com"
  }
}

# Make stuff auth protected
auth.backend = "htdigest"
auth.backend.htdigest.userfile = "/etc/lighttpd/lighttpd-htdigest.user"
auth.require = ( "/phpmyadmin/" =>
                 ( "method"  => "digest",
                   "realm"   => "admin",
                   "require" => "user=ned"
                 ),
                 "/squirrelmail/" =>
                 ( "method"  => "digest",
                   "realm"   => "admin",
                   "require" => "user=ned"
                 )
               )

# Password protect neocapitalism.org
$HTTP["host"] =~ "^(www\.)?neocapitalism\.org$" {
   auth.require = ( "/" =>
                    ( "method"  => "digest",
                      "realm"   => "admin",
                      "require" => "user=ned"
                    )
                  )
}

Among the many things which this config does, it rewrites any accesses to http://vps.nedprod.com to use https: instead. It also redirects any usage of phpmyadmin in the other virtual domains (as the ubuntu package overlays itself on all virtual domains) to use the vps one. And it sticks auth digest blocks round stuff.

After all of that, here's my memory usage on a reasonably loaded server:

             total       used       free     shared    buffers     cached
Mem:        262144     257672       4472          0       9608     189216
-/+ buffers/cache:      58848     203296
Swap:            0          0          0
Total:      262144     257672       4472

So that's about 58Mb used at this stage - MySQL (sans InnoDB), lighttpd plus four php5-cgi processes eat up 28Mb of RAM.

5. Setup Firewall + Email + Spamassassin

The best thing to do is to follow the excellent guide at http://flurdy.com/docs/postfix/ which covers setting up Shorewall, Postfix, Courier IMAP and integrating both into MySQL. You need to skip the Amavisd and ClamAV steps however because they chew up 170Mb alone and will reduce your poor server to a crawl. Be careful to use Shorewall to block off public access to anything until you are absolutely sure it is secure.

Instead, chain in spamassassin manually as follows. Edit /etc/postfix/master.cf:

#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       y       -       1       smtpd
   -o content_filter=spamassassin
#submission inet n       -       -       -       -       smtpd
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#smtps     inet  n       -       -       -       -       smtpd
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#628      inet  n       -       -       -       -       qmqpd
pickup    fifo  n       -       -       60      1       pickup
cleanup   unix  n       -       -       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr
#qmgr     fifo  n       -       -       300     1       oqmgr
tlsmgr    unix  -       -       -       1000?   1       tlsmgr
rewrite   unix  -       -       -       -       -       trivial-rewrite
bounce    unix  -       -       -       -       0       bounce
defer     unix  -       -       -       -       0       bounce
trace     unix  -       -       -       -       0       bounce
verify    unix  -       -       -       -       1       verify
flush     unix  n       -       -       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
proxywrite unix -       -       n       -       1       proxymap
smtp      unix  -       -       -       -       -       smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay     unix  -       -       -       -       -       smtp
	-o smtp_fallback_relay=
#       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq     unix  n       -       -       -       -       showq
error     unix  -       -       -       -       -       error
retry     unix  -       -       -       -       -       error
discard   unix  -       -       -       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       -       -       -       lmtp
anvil     unix  -       -       -       -       1       anvil
scache    unix  -       -       -       -       1       scache
#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent.  See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
#
# See the Postfix UUCP_README file for configuration details.
#
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
#
# Other external delivery methods.
#
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix	-	n	n	-	2	pipe
  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
mailman   unix  -       n       n       -       -       pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}

spamassassin unix -     n       n       -       1       pipe
        user=spamd argv=/usr/bin/spamc -f -e    
        /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Edit /etc/default/spamassassin to make sure you set up spamd to run under the spamd user rather than as root and limit its children to one seeing as each child will chew up 50Mb or so. Spamassassin alone eats 30% of my 256Mb VPS - it's the single largest memory hog by far. Run sa-compile after every sa-update to help reduce memory usage and improve throughput, and don't forget to enable loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody in v320.pre to enable the compiled rules.

After all of that we get the following major memory hogs:

top - 20:25:49 up 2 days, 21:07,  2 users,  load average: 0.00, 0.00, 0.00
Tasks:  65 total,   2 running,  63 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 99.3%id,  0.7%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    262144k total,   258992k used,     3152k free,     6416k buffers
Swap:        0k total,        0k used,        0k free,   130656k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
10103 spamd     15   0 32036  28m 2176 S  0.0 11.2   0:00.09 spamd
10102 root      15   0 31296  28m 2328 S  0.0 11.0   0:00.71 spamd
 1962 www-data  15   0 21004  10m 4152 S  0.0  4.1   0:06.34 php-cgi
 1886 mysql     15   0 55660 8064 4580 S  0.0  3.1   0:00.23 mysqld
11878 postgrey  18   0 10976 7968 2444 S  0.0  3.0   0:00.02 postgrey
 1964 www-data  15   0 18172 7904 4112 S  0.0  3.0   0:02.70 php-cgi
 1961 www-data  16   0 17724 7500 4140 S  0.0  2.9   0:03.08 php-cgi
 1963 www-data  16   0 17308 7052 4124 S  0.0  2.7   0:03.97 php-cgi
 1960 www-data  25   0 16448 4960 3248 S  0.0  1.9   0:00.00 php-cgi
 1957 www-data  15   0  6676 2868 1400 S  0.0  1.1   0:00.06 lighttpd
10347 postfix   15   0  5600 2476 1808 S  0.0  0.9   0:00.00 tlsmgr
 9134 postfix   15   0  5276 1784 1444 S  0.0  0.7   0:00.00 qmgr

And we have the follow memory free:

             total       used       free     shared    buffers     cached
Mem:        262144     259044       3100          0       6504     130664
-/+ buffers/cache:     121876     140268
Swap:            0          0          0
Total:      262144     259044       3100

You can see the hefty effect of spamassassin - we have roughly doubled our memory usage to ~120Mb which is as far as we want to go if we want to keep our 256Mb server running smoothly.

6. Setup Reverse DNS + SPF

Not setting up your reverse DNS will penalise any email you send from your VPS by spam checkers, so here's how. Firstly, most VPSs don't have DNS delegated to them so there is no point setting up your own bind or npd server unless you want a local caching nameserver (not a lot of point seeing as your VPS provider has a perfectly good equivalent nearby) - therefore, you should ask your provider to add the rDNS for your IP, or else use a DNS provider which lets you have access to your host records (e.g. the very reputable though slightly more expensive namecheap.com).

For SPF you need to add an IN TXT record to your DNS record detailing every server which could send email for your domain like as follows:

"v=spf1 a mx include:ukfsn.org ~all"

The include: is for when you may send your email from your ISP's smtp server instead e.g. if you don't set up your SMTP service on your VPS to send email for you.

7a. Content Management

I have spent the last two months looking for a decent content management system and I have installed over ten different CMSs and database driven systems. I was looking mainly for an integrated forum, wiki, issue tracker and database-driven display plus automatic generation of search engine friendly data as well as disability support and any other easy freebies XML enables. This website, nedprod.com, still runs along a static HTML data system whereby I edit the content on my computer, munge it through some Python scripting and upload it via SSH. nedprod's pages do contain PHP to implement little things like the hit counter and automatic page compression (this halved my bandwidth requirements instantly) but all in all, nedprod's architecture would be entirely familiar to someone in the mid 1990s. I'm happy with this system - it works fine for me and gives me the kind of absolute control that I like without being needlessly annoying on a daily basis. However, Google takes special notice of the main CMSs nowadays and it doesn't understand nedprod's data format. Besides, it was about time I modernised my web programming knowledge - I can't live in the 1990s forever!

What follows are only the ones I tried which I thought anything of - as you'll notice, they all have the reputation for being very lean and fast (I didn't even consider them unless they had a reputation for speed). Obviously, I didn't spent a massive amount of time on each CMS so you can take my opinion at the time of writing (Autumn 2008) for what it's worth:

• Dragonfly CMS v9.2.1
  This PHP based CMS was pretty good for what it did - easy to install, plenty of options, responsive, good for forum support especially. I'd recommend it if I were running some sort of mainly-forum & discussion based site.
  
• Trac v0.11.2 (from Ubuntu repositories)
  This Python based all singing all dancing collaborative development tool was a pain to get working - lots of command line work even with the convenient Ubuntu repository install. I got it working eventually, but it was unresponsive to use and the half second lag between page loads was annoying - maybe due to the SQLite3 backend, maybe just cos it's Python. I got rid of it fairly quickly.
  
• Redmine v0.8 (from its Subversion repository)
  This Ruby on Rails based "Trac improvement" was everything that Trac wasn't. It was MUCH more responsive and has a much cleaner UI. Unfortunately, it was a bitch to install because Ubuntu's Rails is broken - not Redmine's fault obviously. Once you hand install an updated Rails using the rubygems package manager, it ran very well except for the 40Mb or so of RAM which Rails needs as a minimum. My only problem with Redmine is that it's a bit simple - fine for simpler projects, not so fine for more complex ones. As much as Trac sucked to use, you can see that it's much more flexible.
  
• Bitweaver v2.02
  This is speed-optimised descendent of TikiWiki. I thought it wasn't bad, fast enough, problem was that its module implementations were a bit simplistic for me. It'll no doubt mature with time.
  
• Joomla v1.5.8
  I tried this because it's one of the "top two" in userbase for the free CMSs. I was fairly stunned in how utterly rigid it is, how lacking in configurability and it's not fast either - good enough with xcache (a PHP accelerator) running, but we're not blazing along here. Why the hell everyone thinks it so great I do not know - I guess if you have absolutely zero knowledge of web programming you'd love its WYSIWYG interface. For me, it was way too toy for real world usage.
  
• Drupal v6.6
  After Joomla, I thought okay I'll try its nearest competitor Drupal. And Drupal is a LOT better than Joomla, but once again I still found it fairly toy. Your page layout is still pretty much fixed, so you still have this notion of "posting news" in order to update content. Maybe I didn't figure out how to change this, but I want the ability to stick any frame I like containing anything I like wherever I like on each & every page and have each page template off a master and sensibly adjust itself accordingly. Drupal doesn't seem up to this - I know that BBC News runs on Drupal so don't get me wrong, it's fine for that kind of website. But it's hardly flexible in its fundamental premise (insofar as I could find). I'd still recommend Drupal over Joomla though - it's much faster and much more configurable, though I couldn't get it to not "feel" different to every other Drupal site out there. You just somehow know it's a Drupal site from how it's laid out and behaves.

Obviously I was getting a bit annoyed by this stage - everything I tried was good in one or two specific areas, but fairly shocking in everything else and I wanted a good performer in lots of areas at once: a one size fits all solution. For example, Drupal is still using a node based layout and page addressing which makes all the URLs some random node number rather than a URL which describes the page content. I had thought that CMSs had moved on by now, though I guess the fact we still need sitemaps.xml would suggest otherwise.

If you're happy with PHP based sites, then great you'll be very happy at this stage - your VPS will handle even fairly heavy loads with ease even without adding a static proxy. Even if you prefer Ruby on Rails, you have ample memory to spare to run two concurrent Rails processes and your VPS will scale moderately well though it'll scale better with multiple logged in users (which are much harder to cache) on PHP. However, I wasn't happy at this stage and I began to wonder what else I could do ...

Read all about setting up Plone & Zope to run on a low-end VPS