Adding Brotli support to nginx

Last year, Google released a successor to the deflate compression algorithm, Brotli. Chrome adopted it in version 51, and Firefox in version 44 (see Can I use…). That said, from the webserver side, nginx doesn’t support it natively, so Google provides the ngx_brotli module, making it just a matter of compiling nginx.

Continue reading Adding Brotli support to nginx

With your own authoritative DNS, dynamic DNS is easy

At the beginning of the year, I wrote about using nsd3 to run my own nameservers: “Authoritative DNS with redundancy, using nsd and Debian Wheezy“. That post focused on the public-facing benefits of running my own nameservers, notably the flexibility it gives me with regard to record types and update frequency.

As I’ve added more and more services to the Raspberry Pis running on our home network, the flexibility I have has demonstrated another benefit: assigning a domain name to the network’s ever-changing IP address. Time Warner doesn’t offer static IPs for consumer accounts, which presents a challenge to using our router’s native VPN functionality. To make it convenient to connect to our home network from afar, I’ve employed an open-source script and a custom DNS zone to provide dynamic DNS via my own servers.

Continue reading With your own authoritative DNS, dynamic DNS is easy

Sorry VaultPress

PHP’s open_basedir is one way I isolate the various PHP applications running on my VPS. Within the directory that holds this WordPress install, there exists a symlink from when I relocated my presentation slides from to VaultPress doesn’t particularly appreciate this:

PHP Warning: file_exists(): open_basedir restriction in effect. File(/.../network/public_html/slides) is not within the allowed path(s).

Letting VaultPress access the directory that the symlink points to would defeat the purpose of using open_basedir, so instead, my VPS continually frustrates VaultPress.

Compiling nginx with OpenSSL 1.0.2 to maintain HTTP/2 support

Chrome 51 disabled support for NPN, or Next Protocol Negotiation, the mechanism that millions of nginx servers needed to establish HTTP/2 connections with Chrome users. For anyone running nginx compiled against OpenSSL 1.0.1, Chrome 51 users are still connecting over SSL, but only via the legacy HTTP/1.1 specification, which lacks the performance benefits HTTP/2 imparts.

Both the nginx project, and Mattias Geniar, provide lengthier explanations of what changed in Chrome 51:

For those wondering how to restore HTTP/2 support for Chrome 51 users, there is but one answer: switch nginx to OpenSSL 1.0.2. While OpenSSL 1.0.1 is only receiving security updates (and will stop receiving any updates after December 31, 2016), OpenSSL 1.0.2 is actively maintained and receiving new features, including the successor to NPN, which nginx supports: ALPN, or Application-layer Protocol Negotiation.

Continue reading Compiling nginx with OpenSSL 1.0.2 to maintain HTTP/2 support

Unintentionally rate-limiting VaultPress

Several weeks ago, I implemented nginx’s rate-limiting mechanism for all services hosted on my VPS. As a result, any non-GET request is subject to quite-low limits on how many requests can be made in a given timeframe. As I discussed further in “Rate limiting: another way I guard against brute-force logins,” I chose very-strict login limits as I’m the only person regularly authenticating with anything I host.

So far, there’s been only one unintended effect from these changes: VaultPress cannot reliably back up my site. Until recently, I hadn’t enabled any server-level access for VaultPress, which forced it to perform backups via HTTP requests triggered from WP Cron events. This approach was fine when requests weren’t limited, but VaultPress now finds itself blocked on every backup attempt.

Continue reading Unintentionally rate-limiting VaultPress

Restricted SFTP access in Debian

As I’ll elaborate on in a few days1, when I added rate-limiting to nginx, I unintentionally blocked some legitimate traffic. Rather than make exceptions for these sources, I chose to provide certain services with read-only SFTP access to the specific directories they require.

It’s worth noting that in my case, I needed to grant particular users, not user groups, access to certain directories. Also, I have no need for any of these special users to access the same items. As a result, the following is tailored to user-level access to discrete directories, but can be set up using groups instead. I won’t detail that here, but the following should be sufficient for one to extrapolate how it would work for groups and shared directories.

Continue reading Restricted SFTP access in Debian

  1. That post started as an introduction to this one, then approached 500 words, which called for excision.

Briefly contrasting StartSSL and Let’s Encrypt

I really want to love Let’s Encrypt, but then I turn to StartSSL. In my case, I’ve a Class 2 validation, so I can issue wildcard certificates with two-year validity. While Let’s Encrypt is automated, the three-month duration is still an annoyance when different applications and programming languages use different CSR, key, and leaf formats. Add to that the need to enumerate every subdomain covered, and I’m prone to stick with StartSSL.

Also, StartSSL now has an API, which was one advantage of Let’s Encrypt. While I don’t issue certificates frequently enough to warrant such an integration, it’s a nice feature to consider for other StartSSL applications.

For me, it comes down to this: I use Let’s Encrypt for the fluctuating, random assortment of domains that I register on a whim and redirect elsewhere, while StartSSL is what I use for domains of permanence or significance. This isn’t a slight against Let’s Encrypt, it just doesn’t suit my particular needs.