Do you love HeidiSQL as much as I do?  It’s really the best MySQL front-end I’ve found so far for Windows.  Sure, MySQL Workbench has all kinds of super-fancy features and GUI tools and what-not.  But, in Workbench, I find that it takes sixteen mouse clicks to perform the same task that you can do in five with HeidiSQL.

I use HeidiSQL for nearly everything, and only have had one major beef with it.  I could never get SSH Tunnels to work with it until today I figured it out! I’m super-stoked.  If you’re having problems with Heidi and SSH too, I’ll provide a step-by-step below (keep reading).

If you want to skip the background junk, and go right to the procedure, be my guest!

First: Why SSH Tunnels?

Okay, if you’re reading this article, I assume you are at-least familiar with MySQL and HeidiSQL.  Chances are, you connect to your database server via the default port 3306.  You open up HeidiSQL, enter your DB Username, password, and host, and away you go.

The problem with this approach is that the MySQL protocol that you are using to transfer your data around is inherently insecure.  Folks sniffing network traffic can intercept your data as it travels over the network.  So, if you care about your data or your database not being hacked, it’s a good idea to encrypt the traffic between your client (HeidiSQL) and your server (MySQL Server).

Insecure MySQL Traffic Flows Across the 'Net as Plaintext

SSH, on the other hand, is a secure protocol.  All traffic between the client and the server is encrypted so that nefarious network sniffer folks can’t decrypt the traffic (easily).

What you want to do is to convert the insecure MySQL traffic to secure SSH traffic on your computer before it hits the Internet.  On the server-side, you want to decode the SSH traffic and pass it along the MySQL server.   Something like this:

SSH Tunnel. All data travels across the 'net as SSH

Setting it Up

First, make sure you know what your SSH username and password are on the server where your MySQL database lives.  Then, follow along:

1. Download Plink.exe.  Plink is a nifty little SSH tool for Windows that allows you easily setup a SSH tunnel.
2. Place the downloaded file anywhere on your hard-drive you wish.  It’s probably a good idea to put it somewhere inside your home directory.
3. Now (this is the step that kept tripping  me up), before HeidiSQL can use Plink to connect to your server, you must download the server’s public key to your computer.
4. So, fire up your command-line, and browse to wherever you put the plink.exe file.
5. Type: plink.exe -L 3307:localhost:3306 [USERNAME]@[YOURSERVER.COM]
6. If it worked, you’ll get a big long message that ends with “Store key in Cache? (y/n)”
7. Say “yes”, of course.  Where does it put this key?  That was a mystery to me too!  It turns out, when you say yes, Plink will put the key into your Windows Registry (at HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys).
8. Type your password, and then type “exit” to finish up this step.
9. Okay, now that you’ve downloaded the key, you’re ready to use SSH Tunneling in HeidiSQL!
10. Fire up HeidiSQL
11. Create a new connection, and choose “SSH Tunnel” from the “Network Type” dropdown.
12. Inside the “Settings” tab, use “127.0.0.1″ for the hostname.  Then, enter your normal database username and password.  Yep, 127.0.0.1 is correct.  You enter the address as if you were logged-in to the server via SSH.
13. Next, flip to the “SSH Tunnel” tab.  Tell HeidiSQL where the plink.exe file is on your hard-drive, then put the actual IP address or DNS name for your database server.  Use 22 (SSH) for the port.
14. Enter your SSH username and password, and then choose “3307″ (or some other unused port) on your computer for the “Local Port”.
15. Let ‘er rip!

If all is well, and the powers-that-be are smiling down on you, you’ll be able to login to click “Open” and everything will work.  Congrats!  Now all your database traffic is travelling through the tubes securely.

If it doesn’t work, it’s time to check your steps or go bother somebody in the HeidiSQL forums.

Happy Friday!

It’s the perfect time to think about it.  With disaster on everybody’s mind, and this being the season of resolutions, it’s time to think about your disaster recovery strategy.

Recently, a major department right here at FSU suffered catastrophic loss to their servers, with scant means of quick recovery.  Their site was down literally for weeks as staff from all over the University scrambled to assist them in recreating the critical pieces.  They lost of a lot of time and money.

I’m absolutely sure they’ll be super-prepared next time, but you don’t have to wait until something tragic happens to be prepared!

Disaster Recovery Enterprise Planning = Big Words (Scary!)

When I was an IT Manager n00b, I thought that planning for disasters was intimidating and complicated.  I thought it took a team of folks working around the clock, military-style, to prepare for incidents.  I was encouraged to believe this by colleagues constantly talking in business-speak, conference sessions talking about things like “DR evaluation metrics”, and by big ugly books that take days to even read through.

In the meantime, while I was being intimidated by all this “enterprise” stuff, we went without reliable backups.  We would have been Scre-ewed if something happened.

1. Embracing Common Sense

Okay, just ignore all that business-speak.  Let’s start with the basics:  If you’re not backing up your data, put down the big ugly DR books right now and go setup a backup.

No, seriously, do it right now.

This does not have to be complicated.  Go find an external hard drive, then find out where your data is on your computers or servers.  Plug the hard-drive into the back of the computers and copy the folders with your data.  Do this every day, and you have a basic disaster recovery strategy!

Pro Tip: If you’re using Windows, I’m a big fan of using Teracopy when I have to copy lots of data at a time.

You get bonus if you copy the data to two hard-drives and take one off-site every day.  Now your data is in two geographic locations on three devices.

See? Easy.  Now that you’re off and running, you can make your life even easier by automating your backups.  If you’re not excited about doing a bunch of geeky tech stuff to get your automated backups working, go convince your boss to spend a few bucks a month on cheap, easy-to-setup online backup services.  If he doesn’t want to spend the money, you can scare him with many horrifying stories of data loss on the Internet.

2. Being Prepared

Next Step: Just sit down in a quiet place for a few minutes and think about the things that could go wrong:

• “My server could suffer a catastrophic hardware failure”
• “My backup data could be corrupt”
• “The building could burn down”
• “We could get robbed”
• “An employee could go apeshit and format the C: drive of the server”
• etc..

Now consider which three or four of those scenarios are most likely to happen in your department. You’ve just considered your risks.  Now, for each one of those scenarios, think about (a) what you can easily do to guard against them and (b) what you would have to do to recover from them:

• Buy a second, backup server (or set an old computer aside to act as server temporarily in case of disaster).
• Keep two backup copies instead of one and periodically test opening files on the backup.
• Take backups offsite so that the data doesn’t burn down with the rest of the building.
• Lock the servers in a room without windows.
• Keep backups (already done), and make sure employees don’t have too much access to the server.
• etc..

If you write all of this stuff down somewhere and tell your boss about it, you have a basic DR plan!  Go have a beer.

3. Building Your Kit

Now that you are creating backups and thinking about our risks/responses, it’s time to build your Disaster Recovery Kit! Put this kit somewhere out of harm’s way, and have it handy in case you need it.  Here’s mine:

1. A camcorder bag — I like this, because it’s easy to carry and has a lot of compartments for all the stuff below:
2. Operating System Boot discs – In my case, Ubuntu Server 8.04
3. GParted Boot disc — For formatting and partitioning systems on-the-fly.
4. Cables – Standard power cable and USB cable.
5. Backup hard drives — Two.  They are my offsite copies of all our data.  I rotate them and keep them encrypted.
6. Flash light – Small and compact, for poking around inside computers or navigating server rooms in the dark
7. Thumb drive — Includes a backup of my server setup procedures/changelogs, systems passwords (in KeePass), and a bunch of portable apps.  Updated weekly.
8. Printed copy of contact information for key stakeholders — My IT colleagues, clients, and my boss, so I can keep them updated.
9. Geek tool kit –  Something like this.  Includes screwdrivers, etc.
10. External SATA Hard Disk Reader – Something small and compact.  In case I need to rip a hard drive from a computer and get the data off quickly.
11. A big sheet of paper that says “Don’t Panic“
12. Music CD with high-energy power music on it.
13. Energy supplement — Or a flask of whiskey, depending on how you roll.
14. “Getting started” guide – A piece of paper, right on top, that explains briefly how to use the kit.
15. Checklist — With all of these items on it, and with weekly DR Kit maintenance procedures.

There, now I can sleep at night much better.  What’s in your DR Toolkit?