Whoops.

As mentioned earlier, I use Varnish to cache static pages on this site to improve performance. I use a WordPress plugin that detects when parts of the site are added or modified (e.g. a new post is published, or an existing one is edited) and it purges the cache for that particular page so the cache content will be refreshed with the new content.

Unfortunately, it was not purging the RSS/Atom feed, so subscribers weren’t getting any updates for several days. That’s very odd.

Until things get resolved with the plugin, I’m manually purging the cache for the feed so subscribers will get more timely updates.

Sorry for the trouble.

Update: What luck! A new version of the cache-purging plugin was just released today and fixes the problem. This pleases me.

On Caching

A flurry of new visitors from Tam’s (hi everyone, welcome!) got me thinking a bit about the performance of this site. Combined with not much going on with gun-related topics here in Switzerland, I figured I’d write a bit about tech.

This site runs WordPress on a S-sized Simple Hosting instance at Gandi‘s Baltimore facility. As a sort of hybrid of shared hosting and a VPS, it has a surprising amount of “oomph”: it has dedicated Apache, PHP, and MySQL processes, uses APC to cache PHP opcodes, and sits behind a series of load-balanced Varnish cache servers which cache static content. It’d make sense to take advantage of those resources to ensure things are speedy.

Out-of-the-box, WordPress dynamically generates each page entirely from scratch: this involves about a hundred database calls and a bunch of PHP work. Considering that content here changes relatively infrequently (yeah, I should write more), it doesn’t make sense to generate each page anew for each visitor since this takes a fair bit of resources.

That’s why I use Lite Cache to cache static content: the first time a visitor requests a page, it’s dynamically generated and sent to them as normal, but the now-generated page is saved on the server in the cache. If a second visitor requests that same page, the cached version is sent to them; since this is just a static file that doesn’t need to be generated from scratch, the server can send it right away, so it loads faster for the visitor. In addition, the static file is stored on the Varnish caches, which are specifically designed for high-performance caching. If the content ever changes (e.g. I make a new post, someone leaves a comment, etc.), the cached version is updated to reflect those changes.

Combined with the front-end Varnish caches, this can swiftly serve up content to large numbers of users — I’ve load-tested it with over 1,000x the typical daily traffic and it doesn’t break a sweat.

That’s cool and all, but why bring it up now?

Because I forgot a critical detail: I only tested it with desktop browsers, where it worked great. However, once someone hit the site with a mobile browser (perhaps on their smartphone or tablet), things went wonky: the site correctly detected that the site was using a mobile browser and generated a mobile-friendly version, which the cache dutifully stored for other visitors. Unfortunately, the cache wasn’t smart enough to tell that all the other readers were not using mobile devices, and started serving up the mobile version to desktop browsers. Whoops.

I’ll make a note to test for this sort of stuff in the future.

Since mobile users make up a tiny fraction of the already-small number of readers here, I’ve disabled the mobile-friendly theme until I can get things sorted out.

Since this is nominally a gun blog, I suppose I should try to connect this situation to guns in some way. Here goes: don’t assume everything will always work the way you think it will. Train for a variety of situations. If your training consists only of calmly standing upright in a well-lit range shooting at stationary targets with a full-sized pistol, you’re not well-prepared for a situation when, for example, a bad guy mugs you with a knife outside your office when all you have is a Beretta Jetfire and a cup of coffee. It definitely doesn’t prepare you for things that go thump in the night.Whether you’re adjusting web caches, training at the range, or sending a rocket to the moon, it’s wise to keep in mind that the universe has a perverse sense of humor.

Relicensing

Effective immediately, I’m changing the license of my content to make it even more free.

Previously, content was licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States license.

I’ve updated to the Creative Commons Attribution-ShareAlike 4.0 International License, which clarifies several issues (particularly for people not in the US). I’ve also removed the NonCommercial restriction.

Of course, this relicensing only affects content that I’ve created. Content created by others remains theirs, and is used either with permission or under fair use.

Breaking stuff for fun and profit.

I spent a bit of the last day or two making some changes to the back-end around here, enabling SSL/TLS for the admin interface, etc.

As far as I can tell, things should be good, but if you find that some functionality has broken please let me know.

For now, I have only the admin interface accessible over HTTPS — all other content should automatically redirect back to the HTTP version and work normally, but in some odd cases browsers seem to ignore the redirects and have formatting issues (cause: the page is loaded over HTTPS but the CSS is loaded over HTTP) and may indicate redirect loops. I’ve been unable to replicate this with testing tools, and it may just be an issue with my browsers. If you see similar issues, please let me know what page you’re visiting, the date and time of the error, and the page source (Ctrl-U) so I can see what might have caused the issue.

Intermittent hosting issues

My apologies if you’ve tried accessing the site and seen error messages, timeouts, slow responses, or other similar issues over the last week or so.

My hosting provider has a rather clever setup that allows for extremely high performance while minimizing resource use. This has generally worked well, but they recently had some issues with their routing hardware that implements this cleverness as well as some moderate attacks against customers.

Although things are stable for now, they’re looking at replacing nearly-overloaded components with higher-capacity models, implementing better monitoring and responses so they can alleviate attacks and detect problems sooner, and otherwise be able to improve things going forward. There may be some instability in the immediate future, but things should improve.

Sorry about the trouble.

Sorry for the inactivity.

Shock! Alarm! There’s actually a new post!

As you might have noticed, I’ve been inactive for the last year or so — things have been extremely hectic in the lab and I’m in the “crunch time” for my dissertation. More soon.

For those who don’t follow it already, I strong recommend reading Shall Not Be Questioned at http://www.pagunblog.com/ — Sebastian and Bitter keep up to date with pretty much all gun-related news and information.

Fear me, for I am root

Google Authenticator Plugin: I’m sorry, but it is not possible for you to import an existing shared secret. You must generate a new one.

Me: Really? That’s annoying.

GAP: Yup. Sucks to be you.

Me: Fine. *generates a new secret* Oh, there’s something I ought to tell you.

GAP: Tell me.

Me: I have root access to the database in which the secret is stored. *edits the appropriate entry in the database, thus restoring the previous shared secret*

WordPress Security: Google Authenticator

Many of the readers here are also bloggers, and quite a few use WordPress.

If you host your own WordPress installation (as opposed to hosting with wordpress.com), you may be interested in the Google Authenticator plugin for two-factor authentication.

If you have an iOS (iPod Touch or iPhone), Android, or BlackBerry device that can run the Google Authenticator app, the Google Authenticator plugin can help significantly with your site’s security. Once you link the plugin and the device, your device generates a new time-dependent numeric code at regular intervals. To log into your WordPress blog’s account you’ll need your username, password, and the numeric code generated from the mobile device application.

This way, even if an attacker manages to acquire your username and password they are unable to log into your WordPress account because they don’t have the correct code. Now an attacker needs something you know (username and password) and something you have (the mobile device that generates the code).

Update: One can also configure a static password for applications that are not able to deal with one time passwords, like desktop or iPhone WordPress clients. Very cool.