Compiling nginx with GitLab CI

Continuing my series on the fun I’m having with GitLab CI, it’s time to discuss using it to automate nginx builds. I’ve previously written about how and why I use a custom build, and a few months ago, I decided to remove the monotony from the process.

Now, when a new mainline release is available, or OpenSSL releases a new version, I update a few CI variables, run a pipeline, and a new nginx binary is available within a few minutes. I’m also able to build for multiple versions of Debian.

Continue reading Compiling nginx with GitLab CI

Automating plugin releases to WordPress.org using GitLab CI

I got started in WordPress development as many do, by writing a plugin. It, along with nearly a dozen others that I’ve released in intervening years, don’t require much attention, so I’ve generally neglected even the most-basic of maintenance: confirming each is compatible with the latest WordPress release and updating the readme accordingly. I’ve felt guilty about this for some time now, but it wasn’t until this weekend that that guilt compelled me to action.

Continue reading Automating plugin releases to WordPress.org using GitLab CI

Monitoring and culling stale GitLab Runner instances

After I set up GitLab’s continuous integration using DigitalOcean Droplets for autoscaling, I noticed that sometimes, a runner would fail, abandoning a Droplet that I’d manually need to destroy. While this problem was infrequent, it was troublesome-enough to warrant some automated solution. Not finding anything readily available, and thanks to DigitalOcean’s godo library, I put together a Go program to periodically cull stale Droplets.

Continue reading Monitoring and culling stale GitLab Runner instances

Four years of HSTS preloading

I recently wondered how long it had been since I added ethitter.com to the Strict Transport Security preload list, as it’s been several years. I added my domain without fully understanding the consequences, though I’ve been fortunate to avoid any problems that could’ve resulted.

Getting back to my original question, version control made it easy to find August 18, 2014 as the date my domain landed in Chromium’s list: https://src.chromium.org/viewvc/chrome?view=revision&revision=290306. At the time, it was one of less than 1,000 domains in the preload list; the bulk of the list was comprised of Google’s own domains. There are currently over 40,000 preloaded domains in Chrome/Chromium. It’s a good thing preloading hasn’t been an issue, it takes a while to get off the list.

Restoring performance after Spectre updates

Two weeks ago, the VPS that hosts this site moved to a machine that had been patched for the Spectre vulnerabilities. Immediately, I began receiving warnings about high load, and these alerts continued unabated for over a week. I tried moving services to other hosts, and I reduced the resources allocated to nginx and php-fpm, all to no avail.

As I continued to monitor and debug the situation, fail2ban regularly appeared among the top resource consumers, but I didn’t think much of it; fail2ban has always been a voracious resource user, but it’s an indispensable tool, so removing it wasn’t an option.

Continue reading Restoring performance after Spectre updates