Episode Details

On today’s episode, we are loaded and ready to go. Lots of OpenBSD news, a look at LetsEncrypt usage, the NetBSD scheduler (oh my) and much more. Keep it tuned to your place to B...SD!

This episode was brought to you by

Headlines

Production ready

• Ted Unangst brings us a piece on what it means to be Production Ready
• He tells the story of a project he worked on that picked a framework that was “production ready”
• They tested time zones, and it all seemed to work
• They tested the unicode support in english and various european languages, and it was all good
• They sent some emails with it, and it just worked
• The framework said “Production Ready” on the tin, and it passed all the tests. What is the worst that could happen?

Now, we built our product on top of this. Some of the bugs were caught internally. Others were discovered by customers, who were of course a little dismayed. Like, how could you possibly ship this? Indeed. We were doing testing, quite a bit really, but when every possible edge case has a bug, it’s hard to find them all.

• A customer from Arizona, which does not observe Daylight Saving Time, crashed the app
• Some less common unicode characters caused a buffer overflow
• The email system did not properly escape a period on its own line, truncating the email
• “Egregious performance because of a naive N² algorithm for growing a buffer.”
• “Egregious performance on some platforms due to using the wrong threading primitives.”
• “Bizarre database connection bugs for some queries that I can’t at all explain.”
• “In short, everything was “works for me” quality. But is that really production quality?”
• “There are some obvious contenders for the title of today’s most “production ready” software, but it’s a more general phenomenon. People who have success don’t know what they don’t know, what they didn’t test, what unused features will crash and burn.”

Using Let's Encrypt within FreeBSD.org

I decided to give Let's Encrypt certificates a shot on my personal web servers earlier this year after a disaster with StartSSL. I'd like to share what I've learned.

The biggest gotcha is that people tend to develop bad habits when they only have to deal with certificates once a year or so. The beginning part of the process is manual and the deployment of certificates somehow never quite gets automated, or things get left out.

That all changes with Let's Encrypt certificates. Instead of 1-5 year lifetime certificates the Let's Encrypt certificates are only valid for 90 days. Most people will be wanting to renew every 60-80 days. This forces the issue - you really need to automate and make it robust.

The Let's Encrypt folks provide tools to do this for you for the common cases. You run it on the actual machine, it manages the certificates and adjusts the server configuration files for you. Their goal is to provide a baseline shake-n-bake solution. I was not willing to give that level of control to a third party tool for my own servers - and it was absolutely out of the question for for the FreeBSD.org cluster.

I should probably mention that we do things on th