Black and White Photography

I began taking a black and white photography class at the North Seattle College continuing education program last week. One week in and it’s just been a bunch of people who are seemingly good photographers show me their photographs and saying “try looking at things this way!” But we had an assignment the first week and that assignment was to take some photographs in black and white and then share them. These are my first week photographs.

Starting off my black and white adventure nice and easy, these are simple lines on a heating vent. I used a macro lens to get the strange focus plane.
This is the view from the inside of John Grade’s Wawona sculpture that hangs in the Museum of History and Industry in Seattle.
These lights are above the lobby and the mezzanine of the UW Tower in U-District in Seattle.
I was pretty fascinated by the patterns that they formed with these lights.
The lights stretched all the way from one end of the lobby to the other and past the elevators and across two floors.

So Long, Alaskan Way Viaduct

Earlier this evening the state of Washington permanently closed the Alaskan Way Viaduct, a scar on the Seattle waterfront since the early 1950s. Before it closed I went down there to take some pictures. I felt that black and white really captured the lack of color that the waterfront has with this behemoth towering over it.

The northbound lanes on the left and the southbound lanes on the right converge to form a two tier highway just south of the Battery Street Tunnel.
The viaduct stretched for 2.2 miles along the Seattle waterfront.
The viaduct definitely made the waterfront feel neglected.
The Alaska Way Viaduct looms over Alaska Way.
This tunnel connected 1st Ave with the Seattle Ferry Terminal. It’s a common place for people to hide from the rain.
Underneath the viaduct was lots of extra parking for tourists and visitors as long as you didn’t mind that your car would be crushed in an earthquake.

Using Let’s Encrypt With HAProxy

Part of rebuilding this website was rebuilding the server and reevaluating all of the technologies that I had put together. Previously I had purchased certificates from Comodo and paid $50 for two year certificates and and hoped that I guessed what names I wanted in the SAN correctly for the next two years. It was expensive and prohibitive toward innovation. So this time around I decided to use Let’s Encrypt. Since Let’s Encrypt has been around for a few years and the EFF is both a founder a major backer I feel pretty comfortable using it.

There are a few things that are unusual about Let’s Encrypt if you’re used to using the last generation of certificate authorities. The first is that you’re required to use their API to generate certificates, though the folks behind it provide very well written and supported tools to use that API. The second is that the certificates only last ninety days, so you’re going to want to automate the process of renewing them.

The tool that you’re supposed to use for generating certificates is called certbot and it’s maintained by the EFF. It automatically creates private keys and certificate requests for you and sends them to the Let’s Encrypt API to get back your certificate. It will also automatically renew your certificates when it is time to be renewed. The API validates that you have control of the domain name or names for which you are requesting the certificate and then sends back the new or updated certificate. It’s as easy as that.

The most common way for certbot to do domain verification is by making an HTTP request to the domain in question and seeing if a special file exists. A lot of guides assume that you’re using Apache or Nginx and that it is serving files from a file system and that certbot can just plop some files on the file system and away you go. Another, less common way to use certbot is to let it run its own web server that serves up the files in question. That less common way is how we will use certbot with HAProxy.

Let’s look at some snippets from our HAProxy configuration file

frontend http-frontend
    bind *:80
    mode http
    log global

    # intercept requests for certbot
    acl letsencrypt-acl path_beg /.well-known/acme-challenge/

    # otherwise redirect everything to https
    redirect scheme https code 301 if !letsencrypt-acl !{ ssl_fc }

    # backend rules are always processed after redirects
    use_backend http-certbot if letsencrypt-acl

    # fall through backend (not defined in this snippet)
    default_backend http-bogus

# this will take challenge requests for lets encrypt and send them
# to certbot which will answer the challenge
backend http-certbot
    mode http
    log global

    # this server only runs when we are renewing a certificate
    server localhost localhost:54321

This snippet listens on port 80, the default port for certbot, and looks for requests to the well known endpoint for Automated Certificate Management Environment challenges. If the request is not for an ACME challenge and it is not encrypted then it will be redirected to https. But if it is for an ACME challenge request then it will go to the “http-certbot” backend where the certbot will be waiting to serve requests on port 54321.

With this configuration all I need to do is point a host name at my server with an A or AAAA or CNAME record and I can get a certificate for it. It doesn’t matter if Apache is actually serving the domain or not. Once the host name is pointed at my server, I only need to run this command to generate a new certificate:

certbot certonly --http-01-port 54321 --standalone --preferred-challenges http --post-hook /usr/local/bin/letsencrypt-reload-hook -d paullockaby.com -d www.paullockaby.com

This will generate a private key and a certificate request and fire up a small web server that will respond to challenge requests from the API and write a new certificate to /etc/letsencrypt. Perfect. What if I want to renew the certificate? That’s easy, too:

certbot renew --renew-hook /usr/local/bin/letsencrypt-reload-hook

Only certificates that are ready to be renewed will actually be renewed by this command. Rather than remember these long commands I actually put them both into shell scripts, like this:

#!/bin/sh

# this fills in the default arguments for creating a new
# certificate. all the caller needs to provide is the "-d"
# argument with a comma separated list of names to put on
# the certificate.
exec certbot certonly --http-01-port 54321 --standalone --preferred-challenges http --post-hook /usr/local/bin/letsencrypt-reload-hook "$@"

You’re probably wondering where this letsencrypt-reload-hook is that I keep referencing. It is the secret sauce to the whole mess. See, HAProxy only likes it when you give it combined private key and certificate files and certbot does not create those. Additionally, HAProxy (like most servers) requires that you signal it when a certificate has been replaced. So that’s what our reload hook does:

#!/bin/sh

set -e

PATH_TO_LIVE=/etc/letsencrypt/live
PATH_TO_TARGET=/usr/local/ssl/certs

if [ -z "$RENEWED_DOMAINS" ]; then
    RENEWED_DOMAINS=`ls $PATH_TO_LIVE/`
fi

# for each domain create a concatenated pem file
for DOMAIN in $RENEWED_DOMAINS; do
    echo "assembling certificate $DOMAIN for sites"
    cat "$PATH_TO_LIVE/$DOMAIN/privkey.pem" "$PATH_TO_LIVE/$DOMAIN/fullchain.pem" > "$PATH_TO_TARGET/sites/$DOMAIN.pem"
    chmod 400 "$PATH_TO_TARGET/sites/$DOMAIN.pem"
done

systemctl reload haproxy

Why do I write the certificates to /usr/local/ssl/certs/sites? That is the location where I have HAProxy configured to load all of its certificates. So I can drop dozens or hundreds of certificates in that directory and HAProxy will load all of them. To accomplish that I put this into my HAProxy configuration file:

frontend https-frontend
    bind *:443 ssl crt /usr/local/ssl/certs/host.pem crt /usr/local/ssl/certs/sites

With this configuration it will load the host certificate first. This is so that clients that don’t support SNI don’t get a random certificate but instead get the certificate for the host itself. After that every certificate in /usr/local/ssl/certs/sites is loaded and the correct cert will be used depending on where the client says it is looking to connect.

That’s literally all there is to it. One script, two commands, and a slightly modified HAProxy configuration file. I’m very happy that I’ve started using Let’s Encrypt to do all of my certificate goodness. I’m not a bank or major corporation so I don’t need advanced verification. I just need things encrypted by a valid certificate authority that will make browsers happy and I don’t want to think too hard about it. This does all of that for me.

A new year, a new blog.

For those of you who still check here you definitely noticed that my blog was inaccessible since Augustish when I decided to take it down. At that time I concluded that the microblog full of quips and pithy comments that I had kept for more than a decade had grown stale and tired. As I get older I can’t keep up the cynicism necessary to regularly populate a microblog. Besides, in the time since I started Twitter has filled that role much better than I can.

So here’s a new website. I gave up writing my own code to maintain a website. Again, as I get older I don’t have the time or energy to keep up a code base for something so mundane as a blog when this problem has been solved a lot. I’ll let people who care more than I do handle the basics of creating websites for me so I can work on things that are actually interesting to me.

Obviously as of this writing the old blog content is not here and obviously as of this writing the theme is a bit spartan. But I’m hoping over some period of time measured in less than years to merge the more interesting things from my old blog into this one and to give the site maybe a bit of color. I’m also hoping to add a page called “Projects” that details some of the code that I’ve written and put on GitHub. I’m also hoping to add a page called “Photography” where I can group together some of the photo projects that I’ve done in the past or intend to work on in the future. Yes, I realize the lack of originality and novelty in my pursuits. But they make me happy and here we are.

There is an RSS feed for blog entries here and an RSS feed for comments. Unfortunately the RSS feeds don’t tell you when the “Projects” or “Photography” pages update so I’ll be sure to write something mentioning when I do updates over there. Comments are enabled for now, too. We’ll see how long that lasts before I get fed up moderating and/or deleting spam.

And here we are. Welcome to 2019.