Posted on by Arnon Erba in How-To Guides

Let’s Encrypt has steadily improved since its public debut in late 2015. Certbot, the most popular Let’s Encrypt client, is available for a wide variety of Linux distributions, making Let’s Encrypt an easy integration for most common web server configurations. However, because of this broad support, and because Certbot offers many internal options, there are several different ways to integrate Certbot with Nginx.

If you run Certbot with the --nginx flag, it will automatically make whatever changes are necessary to your Nginx configuration to enable SSL/TLS for your website. On the other hand, if you’d prefer to handle the Nginx configuration separately, you can run Certbot with the --webroot flag. In this mode, Certbot will still fetch a certificate, but it’s up to you to integrate it with Nginx.

Once you’ve obtained certificates from Let’s Encrypt, you’ll need to set up a method to automatically renew them, since they expire after just 90 days. On Ubuntu 18.04, the “certbot” package from the Ubuntu repositories includes an automatic renewal framework right out of the box. However, you’ll also need to force your web server to reload its configuration so it can actually serve the renewed certificates (more on this below). The packaged renewal scripts on Ubuntu won’t restart Nginx unless you used the --nginx flag to request certificates in the first place. If you’re using --webroot or some other method, there’s an additional important step to take.

Automatically Restarting Nginx

On Ubuntu 18.04, Certbot comes with two automated methods for renewing certificates: a cron job, located at /etc/cron.d/certbot, and a systemd timer. The cron job is set to run every 12 hours but only takes effect if systemd is not active. Instead, the systemd timer (visible in the output of systemctl list-timers) works in tandem with the certbot systemd service to handle certificate renewals.

Instead of modifying the cron job or the systemd service, we can change Certbot’s renewal behavior by editing a config file. Add the following line to /etc/letsencrypt/cli.ini:

renew-hook = systemctl reload nginx

This will cause Certbot to reload Nginx after it renews a certificate. With the renew-hook option, Certbot will only reload Nginx when a certificate is actually renewed, not every time the Certbot renewal check runs.

A Little Background Information

If you’re new to Let’s Encrypt, and you’re wondering why you need to automatically renew your certificates and restart your web server when you get new ones, it’s a good thing you’re here. While “traditional” SSL/TLS certificates are manually requested and can be valid for up to two years, certificates from Let’s Encrypt are only valid for 90 days. In their blog post, the Let’s Encrypt team explains their reasoning behind such short certificate lifetimes: they limit the time period for damage to be caused by stolen keys or mis-issued certificates, and they heavily encourage automation, which is key to the success of the Let’s Encrypt model.

This means that you’re going to need to automatically renew your certificates in order to take full advantage of Let’s Encrypt. Fortunately, since this is how Let’s Encrypt is designed to work, auto-renewal functionality is built directly into Certbot, the recommended ACME client for Let’s Encrypt.

A slightly less obvious question is why you’d want to automatically restart your web server as well. The answer is simple: web servers, such as Apache or Nginx, don’t read your SSL/TLS certificates directly from disk every time they need them. Instead, they load them into memory along with the rest of the web server configuration. This is great, and perfectly normal, since reading the certificates from disk would be horribly inefficient. However, it means that updating (or renewing) a certificate with Let’s Encrypt won’t directly change the certificate that Apache/Nginx serves when a page is requested. Instead, the web server must be restarted in order to load the new certificate into memory.


Posted on by Arnon Erba in Meta

When I left Blogger for WordPress in 2016, I made a deliberate choice to leave some features behind. Part of the allure of WordPress was the opportunity to explore PHP and to take as much ownership as I could over the inner workings of my blog. Blogger, by nature, never provided the level of customizability I was searching for, but the the chance to write my own custom WordPress theme was too appealing to pass up. Suddenly, I had the ability to customize, rewrite, and (more often than not) break almost everything that governed how my content was displayed on the Web.

Taking control did not come without tradeoffs. As previously mentioned, I never implemented comments, and until my massive update in May of this year I had some minor SEO problems like poorly apportioned <h1> tags. However, I had a platform that allowed me to experiment with web technologies on a much larger scale than before.

That was fine, because that was the point. I don’t blog for ad revenue, or to become famous (though I have my doubts that running a technology blog is really the quickest path to Internet fame). Regardless, in the spirit of constant improvement, I’ve been slowly adding features to my blog as I feel it needs them.

Once I finished some SEO work and some performance optimization, the next task was to fix the comments. I’ve implemented the generic WordPress comments template and enabled the discussion section for everything but my archived posts. In fact, I can tell it’s working, because I’ve already blocked dozens of Russian spam comments. Please enjoy.

Posted on by Arnon Erba in News

On Monday, CentOS 7.6 (1810) became generally available for download. CentOS 7.6 follows the October release of Red Hat Enterprise Linux 7.6, as CentOS is the open source community-supported rebuild of Red Hat Enterprise Linux (RHEL).

A list of changes, deprecated features, and known issues can be found in the release notes for 7.6. Notably, the golang package is no longer included in the default CentOS repositories, and instead must be installed from the EPEL testing repository as discussed in the release notes.

You can trigger an upgrade to CentOS 7.6 in one step by running:

yum clean all && yum update

The upgrade requires a reboot to load the new kernel version. After upgrading, you can check your new distribution and kernel versions by running cat /etc/system-release and uname -r, respectively.

Posted on by Arnon Erba in General

You’ve probably heard of RFC 2324, the iconic 1998 April Fool’s joke that gave the world the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0):

Any attempt to brew coffee with a teapot should result in the error code “418 I’m a teapot”. The resulting entity body MAY be short and stout.

Some of the nerdier among us may even remember the IPv10 RFC draft, an elaborate piece of delusion or trolling still going strong after almost two years. Of course, we all know nothing helps reduce the number of competing standards like adding more competing standards [obligatory XKCD].

However, to locate true genius, we must peruse the list of April Fools’ Day RFCs and select one from April 1st, 1990. Yes, it’s none other than the one and only RFC 1149, a.k.a. IP over Avian Carriers (IPoAC). In perhaps the best form of proof that IP can be adapted to run over almost any physical link imaginable, RFC 1149 lays out the basics for a working IP-based network using carrier pigeons.

Really, no one can describe IPoAC better than its creator, David Waitzman:

The IP datagram is printed, on a small scroll of paper, in hexadecimal, with each octet separated by whitestuff and blackstuff. The scroll of paper is wrapped around one leg of the avian carrier. A band of duct tape is used to secure the datagram’s edges. The bandwidth is limited to the leg length.

If you haven’t read all of RFC 1149, it’s only two pages and is certainly worth the read. When you’re finished, you can read RFC 2549, David’s quality of service-enabled extension to the original IPoAC spec. I’ll leave you with this absolute gem from that follow-up RFC:

The ITU has offered . . . formal alignment with its corresponding technology, Penguins, but that won’t fly.

All jokes aside, this is a good reminder that anyone can submit their own RFC, and that you probably shouldn’t believe everything you read on the Internet.

Posted on by Arnon Erba in How-To Guides

Julia, the fast-moving and popular open source programming language for scientific computing, allows for the usage of multiple BLAS implementations. Pre-built Julia binaries ship with OpenBLAS due to licensing restrictions surrounding the Intel Math Kernel Library, but by building Julia from source you can replace OpenBLAS with a free copy of MKL obtained from Intel’s Yum or Apt repositories. As of the time of writing, there are instructions for this process on the Julia GitHub repository.

Determining the BLAS Vendor

Regardless of which BLAS implementation you choose, it is nice to check that Julia is actually using the one you want, especially if you are building Julia from source. In recent versions of Julia, you can run the following two commands in the Julia REPL to find your BLAS vendor:

julia> using LinearAlgebra
julia> LinearAlgebra.BLAS.vendor()

The second command should output a string indicating which BLAS implementation your Julia installation is currently built with.

Posted on by Arnon Erba in News

This September, iOS 12 brought software optimizations to a wide range of Apple devices, but one seemingly minor change to the iPad keyboard has confused users and prompted a slew of complaints. For no clear reason, Apple reversed the layout of the “.?123” and emoji keys in the bottom left of the keyboard, throwing off users who expected to find their punctuation and number keys in the usual location.

Notably, iOS 12.0.1 brings a fix for some charging and Wi-Fi issues that iPhone XS users have experienced, but it also restores the iPad keyboard to its pre-iOS 12 layout. This should be a welcome change for users who are accustomed to touch-typing on their iPad keyboards.

iOS 12.0.1 is immediately available for download on all supported devices.