A few days ago, I wrote about how I built a system for monitoring the weather using Arduino, and InfluxDB and Grafana. InfluxDB is a wickedly cool Time Series Database, which makes it super easy to store time-based measurements, such as weather measurements, but also more traditional metrics, like server CPU and disk utilisation. In the past, I’ve used Munin, an RRDtool based monitoring utility, but it feels kind of clunky these days, and RRDtool can be a bit of a bugger to extract data back out, and there’s a certain degree of lossy compression in the graphs too, which can make particularly spiky events look a lot smoother than perhaps they might be. ...

The weather has always fascinated me, ever since I was a little kid. Watching clouds grow through sunny summer days, the eventual abrupt rainfall and cacophony of an evening thunderstorm. Sudden run-for-your-life rainfall, and gusty winds that send everything scattered across the yard (https://www.youtube.com/watch?v=FRIaKMdO-Vw). Over the years, I have built many little widgets and gadgets for measuring and observing the weather, from homemade anemometers made of 2 litre soda bottles, to seaweed hygrometers and a balloon barometer. ...

I’ve been playing with 2-factor authentication a lot lately, either commercially / within the enterprise with RSA SecurID, or at home, with a variety of services, such as Google Authenticator, Symantec VIP and most recently, Duo Security. RSA SecurID is a bit of a pain to set up, but it does seem to work well in the enterprise. It’s too expensive to consider for home use, but for a VPN, it’s pretty good. ...

A few months ago - quite a few months ago now actually, I started a project looking at the potential replacements for traditional AntiVirus (AV). Note: I use the terms virus and malware pretty much interchangeably in this article, antivirus and antimalware too. I’m wrapping a bunch of different types of malware and virus up with trojans and worms and ransomware and everything else that you get into a single thing. ...

This might read a little bit like an advert, but it’s not. I’m not getting paid for this. I like to talk about things that make my life easier, and there’s going to be a few more in this mini-series. I’m just gonna come out and say it. Patch Management is hard, but it needn’t be. The following comes from my personal experience of managing patches and software updates in an enterprise environment for the last 4-odd years. ...

Whenever we have planned (and sometimes unplanned) downtime, at work, I’m usually asked the question “While we’ve got the entire system down to do X, shall we do Y also?” Typically X is planned, and we’re doing major maintenance - There’s one coming up when there’s grid circuit maintenance, where we’re hoping it’ll be fine on UPS and emergency generator - with an at-risk period. Occasionally, X is unplanned, like the time that the air conditioning failed, and everything shut down to save itself. ...

This article suffers from severe linkrot. It’s been a while since I wrote Parts 1,2,3,4 on my Ansible Tutorial series, but I’ve recently changed my approach somewhat when using Ansible, and certainly when I build on Parallax. I’ve started using more and more from Ansible Galaxy. For those of you who don’t know, Galaxy is a community “app store”-like thing for sharing reusable Ansible Roles. https://galaxy.ansible.com/ Let’s pretend we want to deploy a staging server for a Python/Django application, using Postgres as the backend database all on a single server running Ubuntu 14.04 Trusty. ...

This article suffers from severe linkrot. You may remember that in January, I wrote a trilogy of blogposts surrounding the use of Ansible, as a handy guide to help y’all get started. I’ve decided to revisit this now, and write another part, about Ansible Tower. In the 6-odd months since I wrote Parts 1, 2 and 3 of my Getting Started with Ansible guide, it’s had over 10,000 unique visitors. I’m quite impressed with that alone. I’ve built the ansible-based provisioning and deployment pipelines for two more companies, both based off my Parallax starting point I’ve been working on since January. That alone has been gathering Stars and Forks on Github. ...

This no longer represents good practices. Use Terraform for deploying resources to AWS instead of Ansible. By this point, you should have read Part 1: Getting Started with Ansible, and Part 2: Deploying Applications with Ansible. If you haven’t, go and do it now. You should also be familar with some of the basic concept surrounding AWS deployment, how AWS works, and so on. So, you’ll have some idea how Ansible uses playbooks to control deployment to target hosts, and some idea of the capability for deploying code from version control systems (in Part 2, we used the Ansible git: module.). ...

You should by now have worked your way through Part 1: Getting Started with Ansible. If you haven’t, go and do that now. In this article, I’ll be demonstrating a very simple application deployment workflow, deploying an insanely simple node.js application from a github repository, and configuring it to start with supervisord, and be reverse-proxied with Nginx. As with last time, we’ll be using Parallax as the starting point for this. I’ve actually gone through and put the config in there already (if you don’t feel like doing it yourself ;) ...