After Mozilla’s devastating report, and both Chrome and Firefox’s decision to stop trusting StartSSL certificates issued after October 28, I had no choice but to replace the certificates I’d obtained through StartSSL.
The process took a few months, mainly due to the associated costs. While most of my StartSSL certificates were replaced with ones issued by Let’s Encrypt, there were a few cases where LE wasn’t appropriate. This primarily impacted domains that have many, many subdomains, however there were also a few cases where Let’s Encrypt’s three-month duration would’ve been burdensome. Ultimately I had to purchase three wildcard certificates, plus three single-domain certificates. With those installed, I’m now free of StartSSL/Wosign. After sixty days, I can rotate the pinned keys, impeding any further use of my legacy StartSSL certificates.
To anyone who follows my posts here, my love of open-source software is well-known. Open-source alternatives allow me to host my own nameservers, email, website, and GitHub alternative, and I’ve now supplanted Slack and automation tools like IFTTT and Zapier.
Continue reading Replacing Slack, IFTTT, and Zapier
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.
Continue reading Upgrading to PHP 7.1
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. 🎉
While it’s no longer necessary because Home Assistant 0.35 introduced native support for Flic buttons, I’m still using the controller I released just before Home Assistant updated. In part, this is because I haven’t taken the time to switch the integrations over to Home Assistant automations. Also, having spent some time on the controller, I am not ready to abandon it.
Continue reading Flic controller for Home Assistant updated with breaking changes
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
Flic buttons are Bluetooth-powered smart buttons that can be used to control other devices via their smartphone apps (Apple, Android), or using any number of integrations they provide on GitHub: https://github.com/50ButtonsEach/.
Continue reading Flic buttons and Home Assistant
It’s been a while since I’ve posted anything new about my experiences with home automation, largely because I haven’t done anything new in a few months. I’ve been busy, and at the same time, things are working as expected, so I haven’t come up with new ideas to test or dreamt up something else to automate (much to my husband’s relief).
That said, I’ve been thinking about replacing our hacked Amazon Dash buttons with something purpose-built. While the hijacked buttons work well-enough, there’s a noticeable delay between button press and response, and their battery life is quite finite. Also, there’s only so much one can do with vinyl tape to make the Dash buttons less of an eyesore.
Enter Flic, one of the only “smart buttons” available right now, and the only one I’ve found that doesn’t require its own hub. Fortunately, they offer a Linux SDK, so I can associate the buttons with one of my Raspberry Pis, rather than a smartphone (alleviating a common complaint about the product). Since the SDK requires exclusive use of a device’s Bluetooth controller, I benefit from having two Pis, and this project is simplified because the Pi I intended to use with the Flic happens to be the one whose Bluetooth isn’t in use.
My first project is to configure the Flic button to toggle the lights on our Christmas Tree. The lights are connected to a SmartThings outlet, which turns up in our Home Assistant instance thanks to MQTT, but Home Assistant is only accessible to my husband and I, while any of our guests should be able to turn on the tree. 🎄