I’ve now updated my home server to Debian 6.0. In the process I’ve decided to also switch to lighttpd from Apache HTTP. I do miss the fact that mod_chroot in Apache was able to basically take care of the dependencies for me and build the chroot daemon startup, but it wasn’t too much work to get everything up and going in a chroot. It ended up one of my plugins (Last.

I’m going to be without internet at home for awhile it looks like. The server this blog was run from was just a computer I had in my apartment. Since that’s going to be down sometime in the near future I decided it was time to figure out something to do in the meantime. The solution was to move this blog to a server I know will stay up while I’m moving.

I decided it was time to have some form of backups in place. Currently all I’m really (automatically) backing up is the WordPress MySQL table since it’s the thing to changes on a regular basis. Everything else on this server can be backed up by hand when/if I make changes. It would be faster if/when something does fail (hard drive most likely) to have a recent full backup image to restore from, but really, a good backup of the MySQL table(s), a backup of important configuration files (since they rarely change, I back them up manually after change(s)), and a backup up various directories that’d be nice to restore quickly (most of which change infrequently.

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, I think I have all the previous issues taken care of. Caching may or may not work, but it’s supposed to be happening now. So mail and DNS lookups work now (DNS only being useful from my side.) So, all-in-all I hope this beast can just run for several months and I’ll see what (if anything) needs to be done in that time. So now that my server should be stable, I’m free to work on other endevors!

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.