Passwordless SSH login

I was fiddling with NFS trying to get it to work (previous post) when after a reboot I run into an odd problem: suddenly I couldn't do a passwordless login any more. Took me a while to figure out but there was a very clear error in the syslog: I had changed the permissions in my server home directory to 777 (allow all) to make sure my problems weren't access rights related and the server refused to look at the ssh keys because of this.

A good reason not to work, mind as you never should set the rights like that.

And, btw, the best way to put your ssh key to the server:

ssh-copy-id -i [identity file] [user]@server.

NFS and bind - no good together

I had problems getting my NFS server to work. The whole client side seemed to have stuck to some state that wasn't anymore (plus I got a few stale NFS handles as a bonus).

In the end the problem was that what I was looking at was a bound directory and that just didn't work. I have a /share directory on the server and I had bound /home to /share/home and this wouldn't work. Once I removed the binding from /etc/fstab and just added the /home directory directly to /etc/exports, NFS started working properly.

I don't have the expertise to figure why this is, I'm just happy I got that fixed.

Transferring an SVN repository to Gitorious

Moving SVN repositories to Git is obviously inherently a good idea since Git is a far better vcs. I needed to transfer a very large SVN repository to Gitorious and it did take me a while to figure out how to do it. Turned out git-svn is not the best tool for this. I tried and it took almost two days to fetch the svn repository as a git repository.

Then I found the svn2git Ruby script and that did the trick. Here's how:

• Start by installing git-core and git-svn. Obviously you also need a Ruby environment and the gem package.
  
• Then install svn2git:

gem install svn2git --source http://gemcutter.org

• Then you need to create a committers list because svn has user id's whereas git uses email addresses to identify committers:
  

  svn log | grep -E "r[0-9]+ \| [a-z]+ \|" | awk '{print $3}' | sort | uniq > committers.txt

• Edit this file so that each user id has a unique email address in the form of

user_id = User Name <user@email.com>

• Then fetch the repository:

 svn2git svn://server/path/to/repo --authors committers.txt

• At this point, create the repository into Gitorious.
• Finally, push the contents to Gitorious:

git push --all git@gitorious.org:project/repo.git

And that's it. Just took me a few tries to get the svn repository converted correctly.

Gaming problems

Gah, it seems I always find the odd problems in SW.

Like when I tried to install Baldur's Gate and BG2 + EasyTutu. EasyTutu is a nice mod that allows you to play BG with the BG2 engine and "easy" refers to the fact it's supposedly much easier to install than the plain Tutu.

First problem I hit was that BG wouldn't install. I found out that I did manage it in safe mode, but that's obviously a bit painful. Later I discovered that setting the computer to Gaming mode with Game Booster also does the trick, which helped a lot.

Anyways, BG and BG2 were installed and patched. Next problem was that EasyTutu failed almost at the last hurdle when it was installing some core files (tutucore.exe is some such) claiming it didn't have access to ".\". Which is directory the installer supposedly created. I think the problem is/was that the directory was created read-only. And after the failure, the install app cleaned the directory.

I got around this by killing the setup with task manager and running the last app by hand. First time I thought I had done something wrong because the game wanted CD 2 in the drive and I didn't realise it was for BG2, not BG. Next day I figured this out, but obviously I needed to install everything one more time.

Plain Tutu didn't install either, instead it crashed.

Now I think I'll risk it and install the Widescreen mod that allows screen resolutions more fit for modern LCD screens.

Another problem I had was with my mouse, a Razer Copperhead. Apparently it's a common problem where the mouse button starts generating double clicks instead of single ones. Fortunately it seems I managed to fix it quite easily by opening the mouse. Here's how:
- The screw that holds the mouse together is under the back slider on the bottom. Just peel off the slider and you should see the screw. Make sure you have the right size screwdriver because it's pretty tight and you might damage it otherwise.
- The top slides off by pulling it backwards. Might be a bit tight, but don't overdo it or you might break something.
- The offending part is a small white button on top of a slightly larger black one. I used a flat-head screwdriver to pull it very slightly up and then I pushed it back down. That's it.
- While you are at it, you might remove the excess lint around the wheel as well.
- Putting everything back together is just a reverse of pulling it apart. It took me a while to get the top back on, but the trick was to push it forward, it doesn't just snap on.

There's an other way that might work if you don't want to open the mouse.

Gitorious installation gotchas

Again I spent couple of days just setting up Gitorious. It's much easier than it used to be thanks to good instructions but still a bit of a pain. The part where most people hit the biggest problems is not setting up the site but repository creation phase which never seems to work on the first go. Here's a few hints on that:

1. Double and triple check you have every package and gem installed and with correct version (config/environment.rb hardcodes versions for some gems). It's really easy to miss one package.
   
2. Check that you have created all the directories required and that they are owned by the git user. tmp/pids is one nasty directory that is easy to forget.
3. If you copy-paste stuff from the instructions, fix the quotation and other special characters! This one is extremely annoying, bit me again. Not only are the quotation marks anything but the ones required I spent a good hour figuring out why the poller wouldn't start. There was nothing in any log to suggest any problems, but it turned out one of the hyphens in the init script was in fact some odd character (an extended hyphen) that I just didn't pick up when looking at the script.
4. I figured out that there was a problem with initialisation by the fact that tmp/pids had nothing in it. So check if there is. You can also do ps -ef | grep poller.
5. You can also try to run the poller from the command line by giving "run" as a parameter. This will print any errors to the stdout.
6. Logs that are of interest that you might want to check: anything in /var/www/gitorious/log, /var/www/gitorious/tmp/pids and /var/log/apache2 as well as /var/log/boot.log, /var/log/boot and /var/log/syslog. All of these might sometimes include clues to what went wrong.
7. Check also that stompserver and git-daemon are running (ps -ef).
8. Make absolutely sure that you have edited the correct section in the config files, it's easy to accidentally edit the development section instead of production.
   
9. And finally, don't try to recreate a repo that failed because the poller wasn't running - doesn't work for me and I again spent an hour trying to find an error that wasn't. Test your setup by creating a completely new repository. I think this is a bug in Gitorious.
   

Useful tools for debugging a DNS server

Having been trying to set up a DNS server and a domain with bind9, I have found the following commands useful:

dig domain.name - queries the DNS server for the information regarding domain.name

dig -x xx.xx.xx.xx - queries the reverse DNS information for IP address xx.xx.xx.xx from the DNS server.

dig has many other uses, too. Very useful tool. One useful parameter is @xx.xx.xx.xx which tells dig to use the DNS server at address xx.xx.xx.xx for the query.

named-checkzone domain.name domain.name.db - Run in the directory where the domain.name.db file is located, this checks that the file is correct.

nslookup domain.name - Gets the IP address and some other info.

Links:
dig HOWTO
named-checkzone manual page
nslookup manual page

A simple developer process with Git

There seems to be quite a few questions about how to work with Git in a project because the whole concept of distributed version control is unclear. My proposal for the starting point for developers new to the concept looks like this (Gitorious is used here as the tool to host the central repository used to share the code):


The idea is to create a new branch for every feature the developer is working on. This helps the merge/rebase operations which in turn motivates the developers to do it often enough. An advanced concept would include quashing the commits with rebase --interactive just before releasing the code to the central repository. This blog post explains how to do it. This would help keep the commit log clean and simple. The feature branch is also a must in my opinion if this feature is used because it alters the history and you never, ever (*) do that to code that has already been released. If the developer works solely on the trunk of his repository, there is a greater risk that he does the rebase to already published code.

(*) See "Perils of Rebasing" in the excellent ProGit book.