Hosting Providers

[sc:internet-category ]Jumblecat is currently hosted on Bravenet, which I’ve been quite happy with over the years, however I’ve been thinking about moving.

It’s not that I have a problem on Bravenet, but more that my requirements have outgrown them.  They’re a great host, but they have one major limitation, no SSL support.

As the threats across the Internet have grown, it’s become more apparent that strong encryption is required even on simple little blogs like mine.

For a few of my other projects that require SSL, I’ve been using GoDaddy hosting, which has been pretty good all things considered.  There are a few quirks with GoDaddy, especially if you do any resource intensive, but short lived, processes.

I have a parked domain on Bravenet that I think I’ll try to move across to GoDaddy and see how it goes, then I can try moving Jumblecat across once all the gotchas are worked out (and you know there will be some 😉

 

Vivaldi

[sc:software-category ]Anyone who has been reading this blog for a while will know that I was a big fan of Opera, right up until they moved to Chromium for their rendering engine.  It wasn’t the choice of Chromium per say (though I do think they had a lot of benefits writing their own engine) but the complete change in direction of the browser.

Opera moved from being a great user experience to being just a clone of Chrome in a single version and the complete lack of features really ended my use of it.

Well it looks like the founder of Opera feels the same way and he’s created a new browser, Vivaldi, which looks like it will bring back the old Opera’s design philosophy.

It’s currently available as a technical preview and it certainly has its limits at this point but it’s already better than the current Opera releases.  While it uses the Chromium engine as well, it looks to be a very tight team developing it and hopefully that will bring the kind of features more advanced users want in their browser.

Upgrading OpenVPN Access Server to Ubuntu 14

[sc:linux-category ]In my last post I talked about my OpenVPN Access Servers and a problem I was having, while working on that I also noticed that they were still running Ubuntu 12.

A while ago I upgraded my Ubuntu server through the in place upgrade process and so I was reasonably comfortable with it.  However as this was the a VM I hadn’t built but instead downloaded from OpenVPN, I decided to take a look around and see if there were any gotcha’s with it.

A search didn’t turn up anything and overall there was a real lack of information on the OpenVPN site.  In the end I decided to simply take a snapshot of my backup node and go through with the upgrade process.

I won’t go in to detail of the upgrade process, you can read my previous post for that, but it went smoothly and after I restarted the server, OpenVPN came up as well.

Of course I needed to test the backup node, which means taking down the primary node.  My first instinct (which in the case was wrong) was to simply shutdown the OpenVPN service on the primary node.  That doesn’t work because UCARP doesn’t actually monitor the service on the primary node, but instead just the IP address.  I decided the simpler way to just shutdown the whole server.

Once down, the backup node took over the services and everything was fine.

I simply repeated the process on the primary node and both functioned as expected.

OpenVPN Failover Failing

[sc:internet-category ]I setup OpenVPN clustering a while ago (ok more than a while) and it’s been working pretty well.  I have noticed though that when I did a failover I wouldn’t be able to connect to the secondary node sometimes.  Which kind of defeated the purpose of the clustering 🙁

Of course I don’t fail over very often, but I had a BSOD on my VM host server a few weeks ago which forced the failover to happen and I noticed it as I was out-of-town for a few days.  I tracked the problem down to how OpenVPN (or more precisely UCARP) handles the failover.

When the primary node goes down, UCARP transfers the IP address to the secondary node.  However my switch/router doesn’t see the change right away as it’s ARP cache still thinks the IP address is associated with the MAC address of the primary node.  If you wait long enough, the router/switch expires the ARP cache and things work again, but that’s kind of annoying when you really need something remotely.

Doing a bit of searching around I found arping, which does an ARP level ping to a device.  Adding a quick call to arping in the activation script (/etc/local/openvpn_as/scripts/) seems to have cleared up the problem.

BitTorrent Sync

[sc:software-category ]Using cloud services to store my data isn’t something I’ve been a big fan of, I do use OneDrive a bit, but only for things that aren’t very important but I need to share with others.

BitTorrent Sync on the other hand looks to solve many of the concerns I have and provide a solution that keeps control of your content in your own hands.

It’s still beta at the moment and I think I’ll wait till it’s out of beta to give it a try, but I’m defiantly interested in it.