Geocaching Swiss Army Knife

Shortly after I started Geocaching I discovered Geocaching Swiss Army Knife (GSAK).  GSAK is an excellent database application that is geared towards tracking all of your caching activities.  I rely on this one program to load thousands of caches into my GPSr, keep track of what I have found (as well hidden) and all of the recent activity in caches I haven’t yet found.  In my experience it is the best program written for this purpose.  There are other applications that can do parts of what GSAK can do but none offer the same complete package.

Sounds great, right?  The only problem I have with this program is that it is written for Windows.  There is no Linux port!  Since I run Ubuntu on all of my mobile computers (and even my work computers), I can only use it on my Windows computer at home.  This (for me) was limiting.  Of course Windows users don’t have a problem with this.  For us Linux users however, we are simply stuck if we need to reload our GPSr units in the field or do any research while we are out of range of the internet.

Wine Is Not A Windows Emulator

Over the years I have tried numerous Linux based tools trying to replace this functionality.  Each time I eventually gave up and went back to doing it in Windows.  One day recently I decided to give the latest development build of Wine (WINe is Not an Emulator) to see if GSAK would work at all.  In past revisions of Wine GSAK would either not load at all or would crash and burn shortly after loading.  After updating my laptop and giving it a shot I found out that it works!  I was able to finally load GSAK and browse around the program without crashing.  What a relief!

So, how did I get it to work?  My Linux distribution of choice as of this writing is Ubuntu 10.10.  The default version of Wine that is in the Ubuntu software repository is version 1.2.  Don’t try to run GSAK in this version as it will not work.  You can find detailed instructions on how to install Wine 1.3 below (summarized):

Run the following commands on the command line:

sudo add-apt-repository ppa:ubuntu-wine/ppa
sudo apt-get update
sudo apt-get install wine1.3

These commands will install the latest version of Wine automatically.  If you already had Wine installed then the upgrade will remove version 1.2 first.  I had the most success by manually deleting the Wine version 1.2 /home/user/.wine directory.  Opening Wine version 1.3 will create these files again from scratch.

You need Wine version 1.3 or higher to make GSAK work.

After you have installed the latest version of Wine and created the new configuration files, download the latest version of GSAK.  Open the command line and browse to the downloads directory.  Enter the following command to install GSAK:

wine GSAK772B56.exe

Latest version of GSAK

Now that the software is installed you can start it up, enter your licensing information and get started!  Once I had finished the installation and tried out a sample database, I was ready to start putting this to use.  I solved the issue of getting the software to work in the first place.  Now I had to solve the problem of portability.  How can I move my GSAK installation around with me wherever I go?  I have desktops at work and at home, a laptop and a netbook.  That’s a lot of devices!  I could be using any of them at any time so what happens when I have my netbook but GSAK is on my laptop?

Dropbox solves this problem nicely.  I am running this service on all of my computers to synchronize my important files everywhere I go.  With so many computers it is virtually impossible to keep up with where my data is.  Dropbox takes care of this completely.  I went to my Windows computer and copied my existing GSAK settings files to my Dropbox folder.  Once you have copied the settings files over you will need to change the Application Data, Database Folder and Backup Folder paths in Tools – Options – General.  As you move from computer to computer GSAK will open up and pull in the latest database information.  It really is seamless!

It is seamless however, until I try to open GSAK on my one Windows computer.  The Application Data and Database Folder settings survive the transition from Linux to Windows.  The Backup Folder path does not change.  It still looks for the last path used.  If you want to back up the database in Windows you have to manually change the options coming and going from Windows.  I posted a note in the GSAK forum asking that the Backup Folder be turned into a variable instead of a hard coded path.  Hopefully that will change in future versions.

So What Doesn’t Work In Windows?

There are two areas of GSAK that still doesn’t work with Wine:

• Split Screen View – This feature doesn’t work at all.  It loads the first cache when the program loads but never loads another one after that.  Sometimes the program crashes when it tries to load.  I only run this view when I am on my Windows computer and I have to turn it off before I go back to Linux.
• Macros – Most of the macros that I am accustomed to using work well in Linux.  Only the macros that require Windows drive letters won’t work in Linux.  That doesn’t affect me very much so I haven’t spent much time on it.

It really works!

So there you have it, GSAK works in Linux!  There are still a few kinks to be worked out but considering that a few months ago it wouldn’t even load properly this is enormous progress.  I hope more of my fellow Linux users will start running it.  Perhaps we can get the last few glitches worked out at some point and have the same functionality as our Windows brethren.  Happy Caching!

Google is testing out this service right now with a limited number of users (present company excluded).  It looks like it will cost $20 to transfer the number and your existing phone account will be discontinued.  Keep in mind that you will be hit with early contract termination fees if you are still in the middle of a contract.  If you have been waiting to port your number when your contract ends however, this is for you!

Now if they would only add MMS and extension dialing support…

Hootsuite.com is one of my favorite online apps by the way.  You should check them out when they have finished resolving this problem…

There’s nothing better than a dose of high octane stress to kick off a week just right.  I came in this morning to find out that no one could connect to the server anymore.  Our office was flooded with calls wondering what was wrong with the e-mail server.  In the past people could have clicked past the expiration error and kept on trucking.  I quickly renewed the certificate, downloaded and installed it.  Then the real problem started.  All of our clients could now access the server but they were getting trust errors.  Turns out the new Thawte certificates need to have an intermediate CA certificate installed.

Thawte uses Intermediate CAs to enhance the security of SSL and Code Signing certificates. Installing the correct Intermediate CAs or CA bundle for the certificate being used is absolutely essential to ensure that users don’t see certificate errors when visiting a website or running software secured with a Thawte certificate.

I didn’t know about this since it had changed in the last year.  After running it by their technical support (they give great chat by the way) I was pointed to an article discussing the issue.  Turns out this new requirement was implemented on June 27th, 2010.  I downloaded the required certificate and added the following line to ssl.conf:

SSLCACertificateFile /usr/local/ssl/crt/cabundle.crt

One quick Apache restart and all is well.  Now it’s noon on Monday.  Time to get the week started!

Beware the security devils!

This is the graphic that you now see when you are visiting a website with a valid certificate that is loading page elements that are not encrypted.  It’s not a terrible thing security wise but nevertheless, beware the red skull of security!  Even though I know it is going to generate support calls I still love it.  Well done Google!

Don't expect any help from the Roadrunner.

The Roadrunner delivery issue at work has been resolved.  I waited all weekend to see if our e-mail would deliver.  Roadrunner’s block on our IP address was never removed.  I sent an e-mail address to postmaster@rr.com with no luck.  There isn’t even an autoreply configured for that account.  All of the other major ISP’s resumed service with us after a few hours on Friday afternoon.  Once I was desperate enough I had to eventually change the IP address of our outbound mail delivery.  Thanks for nothing Roadrunner, I fixed it myself.

56FE71501A1C 1695 Fri Jul 30 08:32:19 noreply@nowhere.com
(host hrndva-smtpin02.mail.rr.com[71.74.56.244] refused to talk to me: 421 4.7.1 - Connection refused - - Too many concurrent connections from source IP)

Due to Roadrunner’s rather draconian inbound rate limit policy, we receive this bounce error almost constantly. A fairly large number of the e-mail that is sent out over our servers is headed for Roadrunner’s system. Given that much of the traffic is generated from local church mailing lists, a delay of a few hours usually isn’t that big of a deal. At least, it hasn’t been up until this week. Once I got in this morning however, I saw that we had almost 5,000 messages in the queue with the same error. Alarm bells went off and the IT Office shifted into DEFCON 1.

Searching through the 5,000 messages quickly showed me that there was one sender who was doing most of the work. Grepping through /var/log/maillog quickly showed me which server the traffic was coming from. Once I had this information handy I shut down the main gateway server to stop the bleeding until I could figure out what was going on. I headed over to the server in question and started searching through those logs as well.

Turns out that there was an old Squirrelmail plugin that the spammer was using to generate plain text spam messages internally. Specifically these were nigerian phishing scheme messages. Since they are plain text, coming to and from legitimate addresses and were constantly changing, they were very difficult for our spam filters to stop. Once I updated the plugins, cleaned out all of the mail queues in question and restarted the affected services we were back in action.

The only problem remaining was to convince my fellow e-mail administrators that we were no longer sending spam. All of the major ISP’s use different filtering systems, real time blacklists (RBL’s) and their own internal policies. This meant visiting each ISP listed in the queue as a bounced message and reporting to them individually that the issue was resolved.

Along the way I noticed that there were two agencies that many of the ISP’s use as a clearing house for online e-mail system reputation. You can sign up your organization and they will independently verify that you are not a spammer. Once you are on their list, the ISP’s that subscribe to their services can verify that you are a legitmate sender. It amounts to a shake down more or less. You have to pay to play. Given the importance of our e-mail systems I decided to go ahead and sign us up. If you need to do the same with your mail servers then visit these companies:

• E-mailReg.org – This service charges $20 for one year of service. After verifying domain ownership they say it will take several days.
• ReturnPath.net – This is the big service that a lot of the major ISP’s use. They charge for their service based on how big your organization is. We received the non-profit discount and paid $200 for the application fee with no monthly fee. This system will take several weeks to verify. You really should sign up for this service when times are good.

All is well now. The spam flow has been stopped and all of our queues are cleaned out. All we can do now is wait on Roadrunner’s rate limits to time out and allow us to resume sending messages.