LinuxJedi's /dev/null

mod_write is an incredibly powerful tool when it comes to converting URLs to something else internally.  Recently someone asked me if I could get it to turn a URL from the form http//www.example.com/?m=3-series to http://www.example.com/m/3-series using a 301 redirect.  After a little bit of thought and playing around I found it could be done using:

RewriteCond     %{QUERY_STRING} m\=([a-zA-Z0-9-]+)
RewriteRule     (.*)    /m/%1?        [R=301]

As you can see this tests the query string for 'm' of a certain format.  This then gets passed to the RewriteRule as %1 (capturing all urls) and the [R=301] treats it as a 301 redirect.  The '?' at the end of the %1 is there to keep the redirect from preserving the query string.

Job done!

Here are a couple of common SVN problems I have come across a lot recently and their resolutions:

svn: Checksum mismatch for ‘.svn/text-base/blah.ext’; expected: ‘f8d45250f7df5561635854165862fdd8?, actual: ‘644f85c4befa671150c5c6ec5fad9885?

This tends to be due to the SVN repository data getting corrupted, this tends to happen with users using SSHFS to get to their working copies.

There are 2 ways to fix this, the first is to remove the directory in question and do an SVN up, this may not always be practical because you can have uncommited changes in the working copy.  The second is to rename the affected file (.svn/text-base/blah.ext) to something else to preserve it, then edit .svn/entries.  You should find in the file a section like:

^L
blah.ext
file
 
2007-08-22T12:26:44.000000Z
f8d45250f7df5561635854165862fdd8
2007-08-21T22:28:44.968799Z
410
hans
^L
gamingzone.php

You need to delete between the two '^L's (preserving one of them).  You should then be able to do an SVN update and the file will be repaired from the repository.

The second issue is when you get this error whilst doing a merge (and probably a few other operations):

svn: REPORT of '/repos/firstpost/!svn/bc/525/trunk’: 200 OK (http://10.1.1.70/)

The fix for this issue is pretty simple, the repository was created using SVN 1.4 and the server software has been upgraded to 1.5.  When you do this the repository databases also need updating to support the new merging featues in 1.5.  To fix this simply run on the server:

svnadmin upgrade /path/to/repo

Both forward and reverse SSH tunnels have proved very useful to me lately on a project I have been working on for Dennis.

Forward SSH

Forward SSH tunnels are used to send ports via. an SSH tunnel, this is useful to get around firewall restrictions if for example a mail port is closed but an SSH port is open.  It also encrypts plain text data in the process.  For the application I was using it for I needed a computer to get WebDAV SVN data in a random remote location from a server that is firewalled out from the outside world (apart from SSH).

For this example port 6500 is open on the firewall to allow incoming SSH.  We are basically telling port 8080 on the local machine to go through the SSH tunnel and come out as port 80 remote end (VPN was not practical in the real solution).  Because we are using named based vhosts on Apache on the remote end we set the local end to use http://localhost:8080/ as a proxy in SVN, this can be done in ~/.svn/servers.  The line to connect is as follows:

ssh -q -p 6500 -N user@remote.server.com -L 8080:localhost:80

The -p parameter tells SSH the port for the remote SSH server.  The user@remote.server.com is the standard SSH login details for the remove SSH.  The 8080:localhost:80 basically states that port 8080 on the local machine should become port 80 on the remote machine.

Reverse SSH

Reverse SSH is used to create a tunnel similar to the forward SSH example, but it is used for the server to connect back to the remote machine down the tunnel instead.

In this example we want a user on the server to connect via. SSH to the remote machine, but we will never know the remote machine's IP.  So we open the tunnel from the remote machine to the server and then the user can connect.  Again we assume the firewall is open on port 6500 for SSH.  When a user is on the server and connects to port 5000 they will reach port 22 on the remote machine (this can be used for other ports and protocols easily though).

ssh -q -p 6500 -N -R 5000:localhost:22 user@remote.server.com

You can see here we are using the -p 6500 again for the SSH port, this time 5000:localhost:22 means port 5000 on the server connects to port 22 on the remote machine.

There are other ways of doing the above such as VPN and dynamic DNS providers, but I think you find this a nice alternative when those solutions are not pratical.

I haven't blogged for a couple of weeks for 2 reasons:

1. I've been on holiday
2. The incompetence of my ex-ISP (Virgin Media) meant that I was cut off when all I wanted was a MAC code to change ISPs!

It seems Virgin Media are not too worried that I work for some of the UKs biggest shelf computer magazines.  After 3 and a half hours on the phone being told lies I really felt like detroying them publically.  Instead a nice guy from Ofcom managed to get my MAC code within 20 minutes.  It still left me without an ISP for a while but at least I wasn't using their crappy service anymore.  If anyone does read this I suggest they never even think of using Virgin Media as an ADSL provider.

As a side note I would like to thank the guys at Zen, they really tried hard to help sort out the mess Virgin Media left behind, way beyond the call of duty.  I am very happy to have them as my main ISP now.

So here is a summary of stuff that has been happening lately:

• I have real proof that Virgin Media's ADSL divison really suck see here
• I had a really wet time in Wales, but still good to see my wife's family again
• I resigned from Dennis Publishing on Monday, my last working day will be the 26th September
• I have a new job working as a MySQL Support Engineer for Sun Microsystems starting 29th September (yay!)
• ndb_watch 0.7 is running later than expected because I keep adding new features