namecheap.com EssentialSSL and Amazon ELB

/

For those using the SSL capabilities of Amazon Elastic Load Balancer (ELB),you often need to upload a Certificate Chain to avoid SSL errors in some browsers.

We use Namecheap and their Comodo EssentialSSL wildcard certs. If you specify “Other” as your server type, you’ll get a collection of files that comprise the Certificate Chain/CA Bundle, instead of a single file (like you’d get if you specified Apache during the CSR submission process). If you haven’t purchased your cert yet, save yourself some trouble and just say you’re using Apache. If you specified “Other” or have found yourself with a bunch of *.crt files, read on.

I am going to assume that you are using OpenSSL. I am also going to assume that you have the same files I do. If this isn’t the case, you could try downloading their CA Bundle, but this may or may not work (or be up to date).

cat EssentialSSLCA_2.crt ComodoUTNSGCCA.crt UTNAddTrustSGCCA.crt 
    AddTrustExternalCARoot.crt > ca-chain.crt

This is all you need to paste into the “Certificate Chain” field in the SSL Cert selection dialog on the AWS Management Console.

While you’re here, have another tip: If the dialog complains about an invalid Private Key or Public Key Certificate, you probably need to PEM encode it. My key was RSA, so this is what PEM-encoding looked like for me:

openssl rsa -in mycert.com.key -out mycert.com.pem

This is then safe to paste into the “Private key” field. If for whatever reason your *.crt file came back in another format, you could also use this same set of steps to encode it (though, my was sent to me PEM encoded already).

Fabric task for notifying New Relic of a code deploy

/

We’ve been doing some playing around with New Relic lately at Pathwright.One of the neat things it does is track when code deploys happen, and how they affect responsiveness and resource consumption.

In order to notify New Relic when a deploy happens, you simply POST to their web-based API with the information you’d like to include (change logs, commit hashes, etc).

We currently do this via a Fabric task, which I figured I’d share. We tend to run this from our deploy task. Enjoy!

import socket
import requests
from fabric.api import run, cd

def notify_newrelic_of_deploy(old_commit_hash):
    """
    New Relic tracks deploy events. Send a notification via their HTTP API.

    :param str old_commit_hash: The previously deployed git hash. This is
        easily retrieved on a remote machine by running 'git rev-parse HEAD'.
    """

    with cd(env.REMOTE_CODEBASE_PATH):
        new_commit_hash = run('git rev-parse HEAD')
        changes = run('git --no-pager log %s..HEAD' % old_commit_hash)

    headers = {
        # Adjust this to reflect your API key.
        'x-api-key': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
    }
    payload = {
        'deployment[app_name]': 'Your App Name',
        # This is also very important to update with your own value.
        'application_id': '1234567',
        'deployment[description]': 'Fabric deploy is fun deploy',
        'deployment[revision]': new_commit_hash,
        'deployment[changelog]': changes,
        'deployment[user]': '%s@%s' % (LOCAL_USERNAME, socket.gethostname()),
    }

    requests.post("https://rpm.newrelic.com/deployments.xml",
                  data=payload, headers=headers)

Switched to Pelican

/

For the last four years, my blog has been powered by Django. As I have foundmyself becoming more and more busy, I have stopped wanting to hassle with keeping things up to date on the server and the application.

After a weekend of tinkering and conversions, I’m now up and running on Pelican. Generation is relatively quick, I like that it uses Jinja, and blogging in Restructured Text is strangely… relaxing? The only downside is that the documentation, while reasonably complete, has some unclear spots (custom page generation and RSS/Atom feed settings in particular).

Ansible first impressions

/

After brief visits with Puppet and Chef for config management,I’ve set my sights on Ansible. It’s late and I’ve been staring at this stuff for way too long today, but here are some early observations:

  • I really like that it is written in Python. Puppet and Chef are great pieces of software, but I spend my days staring at Python. It’s nice not having to context switch away.
  • The documentation, while organized somewhat weirdly, is surprisingly thorough and helpful. I found myself much less frustrated and overwhelmed in comparison to my forays into Puppet and Chef.
  • It’s just SSH.
  • The playbook organization and format make a lot of sense to me. It feels a whole lot less complex than Chef in particular.

As far as negatives:

  • The documentation is very good but it could use some organizational tweaking. The related links at the bottom of some of the pages are very erratic and sometimes incomplete.
  • If you’re wanting to use Ansible as a Python API, the docs for this are pretty incomplete.

So far, Ansible looks very promising. I think this is going to be a great fit for us at Pathwright. Perhaps we’ll even have some time to contribute improved docs.