Thursday, 23 July 2009

Sansa Clip Firmware upgrade

Just sucessfully updated the firmware on my sansa clip player following
This thread

Did not need to resort to the windows method :)

Thursday, 16 July 2009

Programming resource

Highly recommended reading, on object orientation and software design in general.

Saturday, 11 July 2009

bash-history - a tip and some thoughts.

A great tip on the Ubuntu-uk podcast this week for keeping your .bash_history file a little leaner (AND MORE SECURE!).

what's the difference between these two lines?

~mysqldump -u user -ppassword mydatabase > backup.sql
~ mysqldump -u user -ppassword mydatabase > backup.sql

well both do the same thing (backup a mysql database to a flat file).
However, the first variant would go into your .bash_history, whereas the second one wouldn't thanks to the space at the line start.

why does this matter?
1. you probably don't want to put plain text passwords into the shell history. It may be convenient, but this file is one of the first places anyone malicious (or simply mischievous) would look to harvest such things if they got physical or virtual access to your machine.

2. perhaps, like me, your .bash_history get's full of stuff like

cd ~
cp -av /home/neil/bashpodder/2009-06-25/ .
mount /dev/sdb /media/player
sudo mount /dev/sdb /media/player
sudo -s
ssh -p 3298 -N -L 2948:
sudo umount /media/player
echo "" >> bashpodder/bp.conf
cd ~/windows_openmolar/openmolar/ && bzr pull

now of those commands, only one or two benefit from being available via arrow navigation. in future, I will be considering putting a space before the majority of my command line playing.

but d'you know what? I think I need to look into the behaviour of bash_history some more. Ideally I would like it to have everything from that terminal session directly available, spaces or no...(in case of typos, which I'll admit happen occasionally) but archive only those without.

I'll bet there's something in the man page... must check sometime.

Thursday, 2 July 2009

tunneling mysql over ssh

Here's my setup for remote access to my mysql server at work.

My work has a dynamically assigned ip from the local provider. I use the free service from to make that ip available. So let's say the hostname I chose from dyndns was
I could ping that address using


I set up a machine at work (machine A) to listen for ssh connections on port 34567
so I can connect to that machine using.

~ssh -p 34567

oh hang on.. my home user "neil" is not allowed, silly me, so let's say I have a known user called "dentist"

~ssh -p 34567

that works!

Now A separate mysql server (machine B) resides on that network. It's LAN IP is
This machine does not allow any other type of connection. What if I want to lever that database remotely? The easiest way is to ssh into machine A (as above) and use the mysql-client command line tool on that machine to connect to machine B.

that command is
~mysql -h -u databaseUser -p

which will prompt for a password. or
~mysql -h -u databaseUser -pPASSWORD mydatabase

which will pass the password "PASSWORD" automatically, and start using database "mydatabase" automatically.

but what if I want to use an application - like openmolar - to connect to that database.

the answer here is to forward the mysql port from machine B through machine A, so that it appears as a service running on my local machine.
here's how.....

~ssh -p 34567 -N -L 45678:

which means...
-p 34567 use "port" 34567 (isn't port a silly term... surely this should be "channel")
-N from the ssh manual - "Do not execute a remote command" I don't fully understand this, but do know the connection is refused if I ommit this.

-L 45678: let's break this down. -L is the command to "bind an address"

45678 is a random port on mylocal machine. is the address of the mysql service on machine B. machine A has permission to connect to this. Also note - 3306 is mysql's standard port.

with that command running, I can now point the app to and I'm golden.