After my server was down for a couple days (because I was physically moving the machine to another location) I decided to check if there were any updates. Sure enough, there just happened to be an update for 3.2 and it had the usual warning of “be sure to backup your database and files” which I either ignore or partially ignore. I do typically do a mysqldump before running any of the updates, but I almost never backup the WordPress directory itself.

I have to say, my server is performing beyond my initial expectations! I think I have everything tweaked to not use massive amounts of RAM (coughMySQLcough.) Here’s how the free -m currently looks: $ free -m total used free shared buffers cached Mem: 121 90 31 0 2 46 -/+ buffers/cache: 41 80 Swap: 1121 14 1107 As you can see, it’s doing pretty good. I’ve even upped the maximum simultaneous Apache connections since it seems to be able to handle that a better now (rather then bringing the server to its knees when something like 10-15 people tried to access it at once.

Well now that the system is live, I think there’s going to be a few things I’m going to need to fix. Most all of them are from using mod_chroot. Most aren’t anything critical, but things that should be addressed (sooner rather than later.) For instance, I think DNS lookups are failing from inside WordPress. I breifly read in the mod_chroot caveates that this may happen, and I think this is happening now.

Well, my server is pretty much ready I now. Apache is chrooted and seems to be working well. I also did a self-signed cert in hopes that’ll make my remote logins even more secure to WordPress. SSH access is limited to keyed logins. Ntpd is running in hopes of keeping the system’s clock sane. I’ve moved all my Git repos here and even have my CGit vhost running/working. Git daemon is also running.

 As I prepare to have my server public, I’ve chrooted my server’s Apache with mod_chroot. This allows me to have the advantages of a chroot environment without as many of the draw backs. There is still some strangeness to work out. For instance “Warning: timezone_open() [function.timezone-open]: Unknown or bad timezone (America/Chicago) in /wp/wp-includes/functions.php on line 3160” I’ll get this figured out, but honestly, it’s not a huge deal. I may have to have Apache load the zoneinfo file, or perhaps not… Really, the only change I had to make to WordPress was to have it connect to the MySQL database on 127.