I use SSH and rsync all the time.

I'd look into <a href="http://www.cablan.net/phpsuexec.html">phpsuexec</a> or similar to keep User A from screwing with User B's stuff, accidentally or otherwise.

FTP is your call, but from an admin perspective, I hate it. Passwords in the plaintext and an apparent history of remote security holes in a number of FTP daemons convinced me to force users to use ssh/scp/sftp.

Apache 2 + PHP + MySQL is the standard combo... lighttpd is nice, too, although I just use it for serving static content. (You can mix it with FastCGI to server PHP as well as -- actually, better than -- Apache, but I haven't, just because I'm a lot more familiar with Apache.)

It seems that you have the basics... I'd just focus on security. phpsuexec will help, as will diligent monitoring. (Make it clear to users that if they don't update their scripts, you'll delete their crap -- old versions of phpBB and such are notorious for allowing people to download remote scripts and run them as the web user...)

Oh, either move ssh to something other than port 22 (I just use 2222), or look into <a href="http://denyhosts.sourceforge.net/">DenyHosts</a>. You'll probably get at least a thousand brute-force login attempts a day. A friend, who's normally on top of security, just had a machine compromised this way: he set up a test user with a generic password, and a brute-forcer got it. Moving to 2222, or any other non-standard port, will dodge the script kiddies for now. On my server, I use DenyHosts to block anyone who fails a login 5 times in a row. I was very careful with user accounts, so they could brute-force all day and not get in, but it annoys me having thousands and thousands of lines added to my logfiles.

I use an onboard adaptec controller for SCSI, and it works tansparently for every OS I have used it on. If you can handle it, try Gentoo Linux: Debian-based, faster than others (if configured right, with no GUI support and architecture opts). ONLY install what you actually need, and it will fly. If you start with a desktop, and a GUI, you will suffer a speed penalty associated with it.

Debug SCSI (I had a bit of fun getting mine working)
- Has the controller ever worked for you?
- If it has two channels, are you using both (it runs faster)?
- Does each drive have a different ID# set with jumpers (they are on the front side of the drive usually)?
- Is the SCSI controller and/or SCSI booting enabled in BOIS?
- Are the drives all making noise and vibrating a bit when on? (A quiet, - non-moving SCSI drive is a dead SCSI drive)
- Are the cables in good shape (buy new ones if not, cables are cheap)? (I just had bad cables confuse me into thinking that stuff was broken)
NOTE: if you have X installed, and use some chubby Desktop Environment (KDE, GNOME) instead of somethign lighter (twm, xfce), just compiling support for the chubby ones hurts performance. TWM is always a solid choice for desktop environments. You should write down a list of the packages you need or want installed (including things like the text-based cursor for copy-and-paste functionality, and lynx for browsing the web GUI-less). Good luck!

You must have far newer SCSI stuff than mine, because my controller can't power them up or down, and it seems strange for the controller to be able to assign IDs (to me at least).