Two weeks ago, I noted that I was preparing to switch from PHP 7.0 to 7.1. It took me a bit more time than expected, thanks to a segmentation fault that appeared in 7.1 when using OPcache.
I’ve been using PHP 7.0 for just over a year, and the 7.1 branch reached its first stable release last month, so I’ve begun thinking about what the switch will entail. Fortunately, my needs are fairly simple, so I only require two additional modules: Redis and GeoIP. I’ve made one hasty attempt to build 7.1 with support for these features, which failed spectacularly; fortunately, the chance that it was an error on my part is quite good, so things may just work when I try it again.
Sadly, I’m not yet able to drop PHP 5.6 support from my VPS as a few necessary applications still don’t work as expected under newer releases.
KeyCDN is rather spectacular. I’ve used them for more than two years now, and their features-for-price are unmatched. Of greatest importance to me, they support custom SSL certificates as part of their basic offering. Given my obsession with HSTS and HPKP (see also), this was essential.
In the last six months, they’ve spared my VPS appreciable traffic:
I can’t recommend KeyCDN enough. I’m told that Brotli and IPv6 support are coming in the first quarter of 2017. 🎉
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.
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.
For quite some time, I avoided acquiring any Rasbperry Pis. I already have four VPS, and I genuinely wanted to avoid expanding the number of Linux instances I was responsible for. My hesitation was for good reason; less than a month after acquiring my first Pi 3, I found a reason to add a second to our home network.
To be clear, I’ve nothing against the Raspberry Pi; I simply knew that my addictive personality would compel me to find ever-more uses for the devices, compelling their multiplication.
As is the case with many things I post, this is mostly a reminder to myself of the math behind
x = 1(execute)
w = 2(write)
r = 4(read)
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.
I recently started a lengthy
cpan update, but failed to do so in a
screen session. I then updated my router’s firmware. Sadly, I had to start the
cpan update again.
I really, really try to start every ssh session with
screen, for this very reason.
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.