Hints for when I configure OpenVPN and Tunnelblick the next time

I've gone through the process of configuring OpenVPN and Tunnelblick at least twice before and I never seem to get it right on the first or second try. This time I'll document a few of the paint points that I experienced even while following the excellent Digital Ocean guide to configuring OpenVPN on CentOS 6.

  1. Follow the "Initial OpenVPN Configuration" section from the DO document.
  2. When generating keys and certificates in the next section, the easy-rsa files are in /usr/share/easy-rsa/, not /usr/share/openvpn/easy-rsa/
  3. Be descriptive when running ./build-key client with something like ./build-key jeremy-home so that you don't get annoyed later that you have a config named "client".
  4. The DO docs don't mention configuring a TLS-Auth key, even though the OpenVPN configuration now has it by default. Do this with openvpn --genkey --secret /etc/openvpn/ta.key before attempting to start the openvpn service.
  5. You'll need a few more lines in client.ovpn to match the server config. These worked last time, but look at the OpenVPN logs when you try to connect for other errors.
    • tls-auth ta.key 1 (the server uses this with 0) to enable TLS-Auth.
    • cipher AES-256-CBC to fix 'cipher' is used inconsistently errors.
    • keysize 256 to fix 'keysize' is used inconsistently errors.
    • tun-mtu 1500 to set the MTU, though I'm not sure this is really necessary.
    • Remove comp-lzo from the client if it's configured. This appears to cause an IP packet with unknown IP version=15 seen error.
  6. Be sure to copy the contents of ta.key into a new <tls-auth> section at the end of client.ovpn so that the client has the same static TLS-Auth key as the server.

Throughout all this, remember that after you drag and drop a configuration file into Tunnelblick, it gets put somewhere else and needs to be manually reloaded every time you make a configuration change to the client.ovpn file you might be working with.

Things are now working with OpenVPN 2.4.4, easy-rsa 2.2.2, and Tunnelblick 3.7.4a.

For the next time I’m trying to figure out how to update the Java SDK

The only reason I find myself having to update Java is to maintain the Elasticsearch server we have running at WSU. Every time I want to update the provisioning configuration, I end up with 25 tabs open trying to figure out what version is needed and how to get it.

This is hopefully a shortcut for next time.

The Elasticsearch installation instructions told me that when they were written, JDK version 1.8.0_73 was required. My last commit on the provisioning script shows 8u72, which I’m going to guess is 1.8.0_72, so I need to update.

I found the page titled Java SE Development Kit 8 Downloads, which has a list of the current downloads for JDK 8. I’m going to ignore that 8 is not 1.8 and continue under the assumption that JDK 8 is really JDK 1.8 because naming.

At the time of this post, the available downloads are for Java SE Development Kit 8u101. I’m not sure how far off from the Elasticsearch requirements that is, so I found a page that displays Java release numbers and dates.

Of course now I see that there are CPU and PSU (OTN) versions. The PSU version is 102, the CPU is 101, what to do. Luckily, Oracle has a page explaining the Java release version naming. Even though 102 is higher than 101, Oracle recommends the CPU over the PSU. Ok.

I go back to the downloads page, click the radio button to accept the licensing agreement, copy the URL for jdk-8u101-linux-x64.tar.gz, and I’m done!

Varying Vagrant Vagrants

I decided yesterday that I wanted to break up with MAMP. While it (and XAMPP) have served their purpose well over the last year or so that I’ve been using them on a regular basis, they don’t come close to mirroring some of the most common server setups out there today for the development that I’m doing.

Most of the smarter setups for PHP dev these days include some combination of nginx, mysql, php-fpm and memcached – at least. The thought of trying to get all of these packages installed and working on a local OS X machine is overwhelming. This computer of mine should be a laptop, not a server.

Luckily, I’m not alone in this dilemma and I got a couple of great replies right off the bat. One came from Tom Willmot pointing me toward some fantastic onboarding docs for Human Made on GitHub that walk through setting up services in OS X. I started down that path because it looked great, but I was also tempted by a reply from Micah Godbolt asking if I had been keeping an eye on Vagrant. That temptation ended up winning the night.

Enter the virtual machine.

I had heard of Vagrant briefly, but had never given it a full chance. I was probably in one of those modes where I would move on if I couldn’t figure it out in less that two minutes. This desire to break up with MAMP finally gave me the will power needed to put in more time.

It turns out that Vagrant is freaking wonderful.

And just over 24 hours later, I have my first draft of a provisioned server up on GitHub as Varying Vagrant Vagrants. It’s fantastic.

I am now able to fire up an instance with a simple ‘vagrant up’ that automatically installs nginx, php-fpm, mysql before proceeding to move config files around and import SQL dumps so that just minutes after the initial command, I can go to an existing dev site in my browser or initiate a brand new WordPress install.


So now I’m on the hunt for more. I’m going to head over to the Portland Drupal User Group meeting tomorrow night for a demo on Vagrant and Puppet and I’m now hoping to start filling my brain with everything Vagrant. There are so many possibilities for sharing dev environments with team members and I can see this turning out to be a ton of fun.

With all that said, get over to GitHub and fork Varying Vagrant Vagrants to see for yourself. I’ve done my best to include some documentation that should get you all the way there, but feel free to reach out if you need some help.