There's additional measures you could think about. They don't do anything for you in terms of actively restricting access though but they're important enough to not leave out.
- The first one is active auditing. The reason I'm listing it is that some people behave better knowing they're watched. Depending on your distribution (in essence: a kernel with SELinux or GRSecurity enabled) you could 0) run the 'auditd' package and set rules (not that hard) that log who accesses what. Without SELinux or GRSecurity you could still run 1) Samhain to check for signs of tampering (changed user authentication or system configuration files) and 2) 'rootsh' to log complete user shell sessions. The dependency would be 0) a remote server these admins have no access to to which you can send syslogs so any activity leading up to any sabotage is safe from tampering and 1) regularly running an auditing tool like SEC or Logwatch to alert you of anomalies or unwanted behaviour.
- The second one is using ACLs (acl.bestbits.at). Placing these admin users in a non-root group and granting them access to the /var/www area may give them enough rights to edit things while still allowing the web server to read and execute content and keeping your admin users from requiring root rights except through specific sudo commands.
- Finally you should have a good (remote!) backup policy in place for the most crucial areas that allows you (or the VPS provider) to restore the system without too much loss should things torun belly up regardless of the cause.

XD is an emoticon, I use too many >.> (There we go again...)

I shall post it when I get back from school, the firewall doesn't let SSH through.