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 :)

Programming resource

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

http://homepage.mac.com/s_lott/books/oodesign.html

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 ~
ls
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:192.168.88.2:3306 dentists@mywork.com
sudo umount /media/player
python
echo "http://feeds.conversationsnetwork.org/channel/itc" >> 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.
Neil.

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 dyndns.com to make that ip available. So let's say the hostname I chose from dyndns was mywork.dyn-alias.com.
I could ping that address using

~ping mywork.dyn-alias.com

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 mywork.dyn-alias.com

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 dentist@mywork.dyn-alias.com

that works!

Now A separate mysql server (machine B) resides on that network. It's LAN IP is 192.168.0.2.
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 192.168.0.2 -u databaseUser -p

which will prompt for a password. or
~mysql -h 192.168.0.2 -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:192.168.0.2:3306 dentist@mywork.dyn-alias.com

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:192.168.0.2:3306 let's break this down. -L is the command to "bind an address"

45678 is a random port on mylocal machine.

192.168.0.2:3306 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 127.0.0.1:45678 and I'm golden.