Category: Tech & Tools

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.

Backups volume

Following up on my backups-focused post from January, I wanted to share some statistics from my BackupPC instance.

Pool is 134.45GB comprising 1,211,118 files and 4,369 directories (as of 2016-05-04 00:34)

This pool dates to February 20, 2016.

There are 4 hosts that have been backed up, for a total of:

  • 87 full backups of total size 1,544.40GB (prior to pooling and compression),
  • 231 incr backups of total size 1,141.75GB (prior to pooling and compression).

As I noted in January, my BackupPC configuration takes hourly snapshots of my three production VPS, performing a full backup every three days. The quantity of incremental backups is what it is because each VPS profile retains all of the incremental backups made between each full backup (72 of them, per server).

Fortunately, the VPS hosting my BackupPC service has 750GB of storage, so my relatively-insignificant consumption rate isn’t a concern.

Generating a CSR with SAN at the command line

Lately, I’ve explored creating my own CSRs for use with Let’s Encrypt, so I can control the common name and subject names. I’m neurotic enough that I can’t bear to let Let’s Encrypt decide.

Including additional domains, a technique known as Subject Alternatives Names or subjectAltName (SAN), requires a configuration file to pass the relevant arguments to OpenSSL.

Continue reading Generating a CSR with SAN at the command line

Sharing Facebook Instant articles is painful

As more publishers apply for Facebook’s Instant Articles program, I find that increasingly, I am avoiding those articles and their purported benefits, instead visiting the original publication’s site for the content.

In particular, I find the experience of sharing an Instant Article to be one of the most-frustrating and off-putting aspects of their efforts, but then agin, that’s what Facebook was hoping for. Extending their desire to confine users to their platform, furthering their closed-source business practices, Facebook created a custom, crippled sharing menu instead of leveraging what the device provides.

Worthless sharing options
The sharing options Facebook does provide are almost universally useless.

If Facebook had simply provided a way to trigger the device’s sharing sheet, the arrangement might be tenable. But as it stands, even with the addition of “Save Link” and “Open in browser” choices, the Instant Articles sharing choices don’t comport with how I consume, save, and share that content. As a result, for every Instant Article I read, I’m forced to use the “Copy Link” option, then open each application I meant to share the item to and complete some other process, before ultimately returning to the Facebook app. While Facebook Instant Articles might speed up the casual reader’s experience, they’ve had the opposite effect on sharing, and therefore on social discovery.