A Day Late

I spent the last hour or so trying to figure out why my Subversion server wasn’t handling diff requests properly. I first noticed it when I was examining a piece of source code and noticed a piece of code I added a while back was missing. Fortunately I’ve been moving all our source code over to a Subversion repository so I pulled up my subversion client and examined the log for the source code file. I noticed a recent revision committed to the repository and suspected that’s where the code was removed. When I tried to display the differences committed in that revision the following error was returned: “GET of ‘/svn/repository/!svn/bc/284/trunk/temp/application.cfm’: 301 Moved Permanently (http://localhost)“.

A quick google search for subversion and “Moved Permanently” returned a link to the Subversion FAQ’s but the answer didn’t seem to help much. First, the question dealt with a commit action which uses PROPFIND as opposed to a diff action which uses a GET request. I still read through the response and verified that the server was in compliance with the suggested configuration. After trying a few different searches I came across this which basically says if your Location tag in your Apache config file maps to /svn then you can’t have a .svn working directory in your document root. Sure enough renaming the .svn directory in the document root allowed me to successfully perform the diff statement but that wasn’t an exceptable solution. Since I want the code for the entire website in the repository, the document root must have a working directory named .svn and renaming it everytime I want to compare differences in a file didn’t seem like a good work around. I was debating changing the Location from /svn to /subvn or something like that but now that we’ve been using the repository for quite a while a URL change wouldn’t be fun.

I spent the next half hour searching the Subversion documentation and website trying to discover where it says you can’t have a .svn working directory if your repository location starts with /svn. I came up empty handed so I tried working the problem a different way. Clearly Apache was handling the GET request for /svn different than it was handling a PROPFIND request for /svn (since commits were working fine). To figure out why it was returning the .svn directory I created a directory in the document root called ‘.test’ and placed a basic index.html file inside of it. I opened my browser and pointed it to ‘http://localhost/test/’ and the index file popped up. However, I noticed the URL had been slightly modified to http://localhost/.test/. It took about 2 seconds for the answer to pop into my head…mod_speling. Mod Speling is an Apache module I installed a while back to help with a case sensitivity problem we were having. We’re moving our site from a windows machine (case insensitive) to a linux machine (case sensitive). To avoid breaking any links that weren’t using the proper case I installed mod_speling which tries to determine what an invalid request is looking for. For example, if a file was named index.html and a request came in for Index.html the Apache server would return a file not found error. With mod_speling the module looks at the invalid requests, sees there is a file called index.html and redirects the request to that file.

So, for my situation mod_speling was intercepting the GET request for /svn/… and was trying to redirect it to /.svn/… To fix the problem I turned off mod_speling on the Apache virtual server handling the subversion repository and the diff worked fine. Fortunately this virtual server is a test server and didn’t really need mod_speling. I was able to keep mod_speling running on the production server where it was really needed. If I ran into the situation where I absolutely needed mod_speling running the same virtual server as Subversion, I’m not sure what the solution would be. I suspect you’d have to turn mod_speling off on the first level of the document root folder entirely. I don’t see any way where you could exclude only the svn directory. I believe it’s a problem with the mod_speling module. Shouldn’t it check the Location tags to see if it’s a valid location before trying to redirect the request? That seems logical to me. If anyone comes up with a better solution, let me know.

As a little disclaimer, I know I’m going to get some complaints about my first post in 5 months being about something technical. I’m sure the complaints will come from the same friends that have complained about lack of updates over the past few months. I’m sorry, I’ll try and post something more interesting soon, but since there was no reference to this problem on the web, and I’m sure someone else will come across it sooner or later, I thought I’d better post it.

Here’s an interesting article about security vulnerabilities that allow the X-Box to be “hacked”.

I’ve had an X-Box for a little over a year now but honestly I don’t use it much. Multiplayer Halo is about all it is used for( Ciara is quite good by the way). I know someone that added a modchip and larger hard drive to their X-Box and turned it into an entertainment machine. He has all sorts of games saved directly to the hard drive and transferred his DVD’s and other recordings to it. It’s an impressive setup. Something I’d like to duplicate if I had the time and/or ambition to do so.

Here’s a handy firefox tip that enables handling urls with line breaks in them. This is particularly useful for those of us still using Outlook, which seems to improperly wrap URL’s quite often.

Here’s another Mozilla/Firefox tip: if you copy a URL wrapped over multiple lines from somewhere and try to paste it into the address bar, you will end up only with the first line of it. To fix it, go to about:config and change editor.singleLine.pasteNewlines setting to 3 or add:

user_pref(”editor.singleLine.pasteNewlines”, 3);

to your user.js file. Now all the line breaks will be removed upon pasting.

I came across a good, free utility to securely (for my purposes) erase a hard drive. It’s called “Darik’s Boot and Nuke” and is available at http://dban.sourceforge.net/.

UPDATE: Perhaps a better solution is to use something I already have. A bootable linux CD with the “shred” utility. The knoppix live CD has this program. For instructions on how to do this, click HERE.

I’ve spent a little time recently doing some simple benchmarking on our MySQL servers. MySQL comes with a nice little benchmarking suite in the sql-bench directory. When I started I was expecting to get a general idea of how our servers were performing under their current configuration. I didn’t expect to discover configuration errors, but discover them I did. I learned our “open files” limit was set too high. I checked the operating system kernel variable and it indicated the operating system would handle 4096 open files / process. However, as soon mysql would exceed 1024 open files it would fail. I set the mysql file limit to 1024 and the benchmark tests completed without any trouble.

So what did I learn from the benchmarking? It’s time to buy some new servers. When I started this job I assumed our servers wer top of the line, in terms of performance. What the benchmarking indicated was the mysql server I have running on this little dual processor pentium 3 machine, in my basement, was outperforming our UNIX servers by quite a bit. I checked into our server specs and discovered they’re only dual 400mhz processor machines (NOTE the benchmarking suite does not utilize dual processors, since the process is serialized). That explains a lot. We’ve started to run into some serious performance issues recently and it appears our processor load is getting to be too much to handle. Fortunately I was able to spread the load across both servers (originally one of them was entirely a test server), which has alleviated our load problems temporarily. That should keep us going until I can replace the servers.

Anyway, if you have some time, play around with the benchmarking suite. It was interesting to see how things changed by modifying a few variables here and there. It was particularly interesting to see the effect on performance by simply changing the tables from myisam to innodb. The sql-bench suite will give you a good idea of general performance but if you want to get serious about optimization I hear the MySQL super-smack program is the way to go. It’s completely flexible and allows you to create custom bechmark tests that will simulate requests and loads your production server will likely be handling.

I was finally able to get DBD::mysql working on one of our HP-UX servers. I removed g++ and binutils using swremove and then downloaded the latest versions from the HP software library and installed them using swinstall.

Once I had the new compiler installed I followed these instructions, from the mysql lists, and everything worked. I had to change one thing from the instructions to get it working. When I executed perl Makefile.PL I noticed my gcc-lib was in a different location. Actually it was basically the same location but since it was a newer version I had to modify the version number in the “-L/usr/local/lib/gcc-lib/hppa2.0n-hp-hpux11.00/3.2.3″ parameter.

I spent a good portion of the afternoon trying to get the perl module, DBD::mysql installed on one of our HPUX servers. I think I’ve decided it just wasn’t meant to be. The problem seems to be caused by the compilers. I downloaded the latest perl binary distribution (5.8.3) for HPUX 11.00 and then downloaded the DBI and DBD::mysql modules. I first tried compiling DBI but the compile failed. It seems the perl binary distribution I downloaded was compiled with gcc using the GNU assembler. However, my system was setup to use the HPUX assembler with gcc. I spent a while trying to figure out how to change assemblers with no luck.

Eventually I decided to try a different binary distribution (5.8.2) which had been compiled with the HPUX compiler (cc). This time the DBI module compiled and installed with no problem but the DBD::mysql failed. The cause was basically the same. Incompatibility between compilers. I tried another binary and this time DBD::mysql indicated that the mysql client was compiled without a required option. I tried to compile a new mysql client binary but that also failed (once again, due to compiler/version issues).

I was ready to try and compile perl on my own instead of using the binary but from all the information I read, it can be an even bigger hassle. I’ve yet to find a post where someone indicated they were able to get DBD::mysql running on HPUX 11.00.

Anyway at the end of the day I was no closer to getting DBD::mysql up and running and I couldn’t help but ask myself if there shouldn’t be an easier way.

UPDATE: I finally got it working. See this post.

I’m still having trouble with our MySQL server. It stops responding at least once a day. I’ve tried just about everything I can think of. I even dumped all the databases, dropped them and imported all the data again. No luck. I think I’ll probably have to install the debug edition and try and figure out what’s locking it up.