Like a lot of people, I ditched my desktop in 2007 and moved to a laptop as my main computer. I take my Macbook Pro to work everyday and it’s also my personal computer at home.

To make life simpler I have an almost identical network set up at home as we do in the office, using the same DHCP range and gateway address (our dev server is also our gateway in the office). So the development server I SSH into at work has the same IP as my home linux box. At work we have internal DNS set up, I’m a little more lazy at home and just refer to my linux box by IP.

A problem arises doing this though; since I connected to the office development server with SSH first, it got first place in my known_hosts file, consequently when I connect to my home linux server (with the same internal IP address) I’m presented with a warning ‘REMOTE HOST IDENTIFICATION HAS CHANGED!’ and I that I could be subject to a ‘man in the middle attack’.

Oh noes!

Of course this isn’t really the case, my linux server just has a different RSA key fingerprint to the office dev machine. There’s two ways we can surpress this…

First Method – disable strict key checking & tell ssh to shut up
When you SSH to a machine for the first time, you’re prompted to save the machine’s fingerprint to your known_hosts file. Your SSH client will save the hostname (if you used one) and the IP address it resolved to:

<hostname>,<ip> ssh-rsa <public key>

I only recommend this for machines on your LAN / inside your DMZ, and not across the public internet.

SSH always resolves hostnames to an IP and complains if two keys for the same IP address exist in your known_hosts. To surpress this you can use the following arguments:

$ ssh -o "StrictHostKeyChecking=no" -q hostname

That’s quite a handful to type, you can alias this command in bash to save your fingers some work.

$ alias sshq="ssh -o 'StrictHostKeyChecking=no' -q"
$ sshq hostname

Method Two – temporarily ignore your known_hosts
Using the -o switch we can redefine the location of our known hosts file to /dev/null by overriding UserKnownHostsFile. Observe:

$ ssh -o "UserKnownHostsFile /dev/null" user@192.168.0.1
The authenticity of host '192.168.0.1' can't be established.
RSA key fingerprint is 35:f8:d4:46:0e:...:9f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.1' (RSA) to the list of known hosts.
Linux hostname 2.6.18-6-k7 #1 SMP Mon Oct 13 16:52:47 UTC 2008 i686

While SSH has said it’s saved your server IP to known hosts, it really hasn’t as it’s writing to /dev/null.

Hopefully these two methods prove more convenient than swapping known_hosts files.

Having recently switched to Mac OS X, I stumbled upon issues when mounting shared folders on my Macbook Pro from our Linux development server. Previously, both Windows Vista and Ubuntu have had no trouble sharing a directory then mounting it from the dev server via smbfs. This enables me (and other developers) to edit files locally which then also appear as a local files to our development server, where we run Apache / MySQL etc.

After sniffing around System Preferences in Leopard, and juggling some account credentials so SMB login details pair up, I could successfully mount my workspace folder. Make sure the appropriate permissions are set on your shared folder, then click options and disable AFP, and enable SMB.

Unfortunately, some minutes later it unmounted itself. After some Googling, I found others with the same issue.

I read (unfortunately I’ve since lost the link) that changing from smbfs to cifs helps remedy this problem. I gave it a shot and it sure enough it cured the dropping issue.

However, when using cifs I would get permissions problems if I ran a script that manipulated / generated files in my workspace. My OS X uid and gid do not match those of the development server (Ubuntu); Mac uids start at 501 and Ubuntu creates users starting above 1000.

Fortunately simply telling the mount to ignore permissions seem to solve the problem. This is the mount entry in the development server’s /etc/fstab:

//192.168.0.1/workspace /home/greg/workspace cifs
      noperm,credentials=/home/greg/workspace.smb,rw 0 0

That should be all on one line but is broken over two for formatting purposes. Of course you substitute 192.168.0.1 with your Macbook’s UNC name or IP address. You should substitute ‘workspace’ with the name of your shared folder and change the mount point on the local server accordingly too.

The username and password specified in your credentials file will have to match your OS X user and password you set up when modifying the sharing options earlier.

I started writing this post some months ago back in September but never got around to finishing it. At first this post was going to be me singing my praises for Ubuntu and how well Ubuntu supports the Macbook Pro. Unfortunately in that time I’ve now moved to Mac OS X…

I ran Ubuntu on my Macbook Pro seemlessly for just under 3 months before upgrading to Intrepid Ibex. The upgrade went smoothly, except for my office printer no longer working. This lead to Ubuntu’s demise on my MBP. After re-installing the driver 3 times I decided I’d remove CUPS in case there were left over configuration files causing issues. Unfortunately I stupidly marked all CUPS components with ‘remove completely’ via synaptic. I then watched synaptic systematically remove nearly all my system packages… nautilus, firefox, gnome, the lot. My bad.

After 3 days of recovering my data and failed attempts to re-install, and have my Macbook boot Ubuntu without live CD assistance, I gave up and installed Mac OS X. This in itself is no fault of Apple or Ubuntu. Apple never meant for Macbook’s to run Linux.

Two issues arose when I moved from Windows Vista running on Bootcamp to native Ubuntu.

1) Rewind to mid-August, after reading up on hardware compatibility, and how to put Ubuntu on my Macbook Pro, I wiped my Windows Vista and OSX partitions and installed Ubuntu 8.04 (Hardy). That was a whole lot of fun – only realising Apple had crippled my “Superdrive” with a firmware update, I couldn’t read my Mac OSX Leopard DVD (I’m not the only one – £400+ for Apple to fix it, no thanks!) and only able to occasionally read the Ubuntu installation CD.

I managed to overcome these hurdles with a trusty 16GB Rally 2 USB stick and a WD Passport external USB hard drive. I even splashed out on an external DVD-RW to make future re-installs easier.

2) In early September I noticed when running on batteries my Macbook Pro would switch off after only 5 mins. No prompts about low battery, no shutdown sequence, nada. Just power off immediately. At the time I put this down to poor power management by Ubuntu. Just last night however (running OS X) it did exactly the same thing. So it looks like another hardware fault on my £1350 (with academic discount) laptop.

The firmware upgrade happened some months ago, possibly autumn 2007 but having no reason to use the DVD drive for months, I never noticed until I switched operating systems. The instant-power-off-issue-with-no-warming issue has only manifested since August. Co-incidentally just as my 1 yr of Apple Care expired.

So despite it’s low profile form factor and decent performance, I vow never to purchase another Macbook again. It’s a regular PC laptop for me next time…

Not long now until Ibex is released. However, I ran into this issue again this morning so I thought I’d document the solution for others.

Occasionally when starting Firefox or Thunderbird on Ubuntu (I’m running Hardy Heron 8.04), the window will lose all decoration. No title bar, no minimize, maximize or close buttons and will maximize to fill the window – making it very difficult, if not impossible to move.

In Firefox, this can be easily solved by pressing F11 twice to jump in and out of full screen mode. Thunderbird has no option so we have to work around. Close Thunderbird then edit the following file:

$ nano ~/.mozilla-thunderbird/xyz1234.default/localstore.rdf

Find the following line and edit the attributes to match those shown here:

<rdf:Description
RDF:about="chrome://messenger/content/messenger.xul#messengerWindow"
                         width="800"
                         height="600"
                         sizemode="normal"
                         screenX="5"
                         screenY="5" />

Credit goes to SvenRieke for this workaround.

I had an opportunity to play with Bash script on Friday. My task was to write a small deployment script to grab our server class configuration settings from subversion and rsync them to the appropriate machines.

This was easy enough, a couple of commands to subversion, rsync and some glue and I’d be done. However, an hour into writing it I wish I’d used PHP or used my time to learn how to do it in Perl.

For one, a hash of arrays doesn’t sit well in Bash script. I wanted to define a list of servers for each class. In PHP the code would have been as simple as:

$servers = array(
  'web' => array('server1', 'server2', 'server3'),
  'db'  => array('server4', 'server5', 'server6')
);

Fortunately I was able to work around this with separate arrays for each class. What I couldn’t get around was the pain I had to endure to pass an array as an argument to a function.

Passing an array involves loading the space-separated elements of the array into a variable with command substitution.

Taken from Chapter 33 of the Advanced Bash-Scripting Guide.

printarray () {
  local passed_array
  passed_array=( `echo "$1"` )
  echo "${passed_array[@]}"
}

original_array=( element1 element2 element3 element4 element5 )
argument=`echo ${original_array[@]}` # command substitution
printarray "$argument"

This is just clunky and showed me that for anything more than basic conditional logic I’m better off investing some time in learning Perl.