| First things first: If it’s a web server, it needs very few user accounts on it. The ultimate reality (though impractical in most cases) is just two users: root (you) and webmaster.
Give the user(s) access via FTP only (something like ProFTP that can be chrooted) with no shell at all (/bin/false). This limits the harm that can be done — if you can, you should firewall port 21 so that the wild and woolly internet cannot reach your FTP server’s control port, to keep things nicely under control. Better yet, firewall all except port 80, and 443 if you need SSL. Install SSH, then yank telnetd out by its roots. Make sure that no shell account has any reason to send a password in plaintext across the network.
If you have to allow for multiple users, so that, say, different departments get their own place in the sun, just take advantage of ProFTP’s chrooting to keep them from clobbering one another’s stuff. If you need to provide mail, I recommend installing qmail but only allowing for delivery by forwarding to the users’ primary accounts, and not allowing for relaying.
As for Apache, make sure you have a plan for keeping users’ stuff segregated, without making them jump through hoops. Only allow overrides on a case-by-case basis — instead of allowing every user on the box to install formmail, instead install cgiemail for them.
If you have to provide email, use qmail. It’s weird until you get used to it, but it’s easy and apparently very secure. If you must provide DNS, use djbdns — BIND has a lousy security track record, is hard to get along with, and is best left to those who enjoy that kind of pain. The best bet, though, is to avoid providing any services that can be shoved off on, I mean, provided by, someone else.
The more services you offer, the more time you will have to spend adminning the thing. Of course, install tripwire and logcheck (or whatever other, similar things you’re comfy with) so the machine can tell you if it’s unhappy, and it should be a set it and forget it installation.
Provide documentation for every service the machine provides to the clueless, er, uh, web authors. Write it yourself if it doesn’t exist.
When it comes to updates, my advice is to, whenever possible, wait a few days before implementing them, and search for references to the affected packages in the mailing list archives before installing. I use one criterion to determine if the update goes in before other users have had time to discover brokenness: Is the bug or hole this update fixes so outrageous that I’d think it wise to shut the machine down if there were no fix available? If the answer is yes (leaking company secrets, exposing the LAN to attack, those kinds of things) then cross your fingers and apt-get. If the answer is no, then let the other users out in the world find the new bugs.
Remember to smile a lot and speak very little when listening to users… it makes ignorance look a lot like wisdom 🙂