LinuxJedi's /dev/null

I have been using Ubuntu Intrepid for over a month now and as the finial release draws near it appears it is going to be quite a disappointing initial release.

Regressions

Intel wireless chips now need to have a country set to make them work on European channels, the problem being that there is no documentation yet on how to do this.  Ubuntu's bugs team has marked this as Low Importance.  I would personally disagree, but I guess its relative and they have more serious regressions to deal with.  This is going to cause massive problems in the near future as wifi chips work on channel > 100 as there are larger variations on which channels can be used in various countries.

VPNC in NetworkManager has turned from something great into a mass confusions of unnecessary dialogs.  The worst part is it just doesn't seem to work properly any more using my company's VPN profile, often not being able to connect to sites through the VPN.  I would fall back to Cisco's own VPN software, but that is known to be unstable with multi-core systems and especially with wifi, often causing kernel lock-ups.

Whatever they did to Bluetooth it really sucks now, sending photos from my Sony K800i to my PC has never been so painful.  Changes to Bluetooth also appeared to the outside to show that Ubuntu doesn't show much regard for the Kubuntu team, I have a feeling if this doesn't change by late KDE 4.2 / early 4.3 then it will really turn to bite them.

There are many other problems but these are a good few to start with.

Theme

We were promised a new theme for Ubuntu Intrepid, there is DarkRoom which is a horrid dark version of Human, and there is a tweaked version of Human with a new background, but beyond that there is no sign of delivery on this.  This I find a real shame as the community came up with some fantastic ideas which with a little development I feel could have pushed Ubuntu a bit more mainstream.

Firewall

Mandriva has managed a pretty good firewall from what I have seen in 2009.0.  Most other distros have firewalls, why doesn't Ubuntu?  Most of the time I am working from my home network which has its own firewall, but I am increasing working at remote sites and abroad.  I need certain ports open for my job (NDB ports, MySQL, SSH, etc...).  Some kind of external protection for this would be nice, with the push for more on-the-move networking options I would have thought this to be common sense now.

Conclusion

All this said there are some interesting improvements, and the new background is very pretty.  I just think there are too many problems to justify the minor enhancements.  I'm sorry Ubuntu but unless you pull something out of the hat in the few days left you have before release I give you a solid C- for Intrepid.

I have already found myself looking at other distributions for my 2H 2008 distro fix, I'm even looking at OpenSUSE which is never a good sign.  I am most impressed with Mandriva, they have made KDE 4.1 into a really useful distribution, its network suite it far more advanced than the NetworkManager in Ubuntu.  Unfortunately Mandriva 2009.0 has too many bugs at the moment for it to a day-to-day distribution for me, but could become a serious contender in the future.

I have been meaning to write a blog entry for a while but time is always against me, so here is an update on things:

• I started my new job in the MySQL division of Sun Microsystems at the beginning of October.  They are a really fantastic group to work for.
• ndb_watch is officially abandoned.  CMON is already a much better product and I cannot even hope to catch it up.
• I went to Montreal last week with the MySQL AMER support team, it was great to meet them all.
• I found a bottle of 'Vim' in a local shop! (see below)
• Hopefully I won't leave it as long before my next blog post

VIM

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.