Redis is very, very good at running as a Highly Available service. It has supported clustering since 3.0.0 was released back in April of 2015. Clustering many redis servers together allows for higher throughput (spreading the load), as well as redundancy (for when servers die unexpectedly).
Here I have assembled some notes about common things you might want to do to your Redis cluster, and how to do them.
Amazon just launched a new service called AWS Certificate Manager (ACM) as part of their ever growing suite of services. The new service allows for more or less one-click creation and deployment of free SSL certificates (yes, free). I used ACM to enable SSL on this very website and it didn’t cost me a dime. Anyone can set up SSL for their own custom domain name in no time at all with this new service.
When using Microsoft SQL Server, enabling Read Committed Snapshot Isolation (RCSI) is one way to prevent reads (SELECT statements) from escalating into full table locks. Depending on your application this can either be a good or a bad thing. I’m not going to get into the why’s and why-nots of each strategy - this is a good article to read if you’re having a hard time deciding which strategy to choose and why.
So let’s say you want to enable RCSI on a fictional database MyDB. This can be achieved by simply issuing the following T-SQL:
ALTERDATABASE MyDB SET READ_COMMITTED_SNAPSHOT ONGO
To check that it was successfully enabled, you can check the System View sys.databases:
WHERE [name] ='MyDB'
If it returns 1 then RCSI was successfully applied, you’re done! Unless…
Documentation is one of those things that’s easy to down-prioritize to the very bottom of your todo list, even though it could be one of the most important tasks that you undertake in your day to day job.
As part of my regular annual website refresh, I decided to take a pretty drastic step and move from WordPress to a static site generator called Hugo. I’ve kept my WordPress install continually up to date since early 2009 and it served me well, but I needed a change. I also went back through the archives and culled all my old blog posts - I only kept the most trafficked and the ones that Future Will might want to reference.
Update: This technique also works in VMware Fusion 8!
I am an OSX user, and I run a lot of VMs using VMware Fusion 7 which I have been very happy with since I purchased it. One thing that always bugged me is that Fusion allocated a different IP address to each VM every time it started up, or resumed from a suspend. Applications that I use that have references to those IP addresses always had to be reconfigured each time I wanted to use them.
More recently, I’ve been testing out lot of different type 1 Hypervisors (ESXi/vSphere, Proxmox, XenServer etc) which usually make the assumption that they will be given a static IP (which they should in the real world).
So imagine my delight when I discovered that you can indeed allocate static IP addresses to VMs simply by editing a single config file.
Amazon Web Services (AWS) provides a really great service-oriented way of creating virtual machines in the cloud with their Elastic Cloud Compute (EC2) system. There’s many reasons you’d want to increase or decrease the size of an EC2 instance on AWS. Maybe you misjudged how much traffic you’d be getting, or maybe you need more horsepower to finish a certain workload in a shorter time.
I used the free Dynamic DNS (DDNS) service from Dyn since about 2006 and never had a single issue with it. That all changed when they phased out their free accounts. I was forced to find an alternative, so I went with No-IP.com which was easy to set up and provided a great service.
Recently, No-IP has been having some legal troubles that seem to be revolving around Microsoft’s crusade to rid the world of spammers/scammers/malware/botnets. My hostname was one of the ones that was nixed by Microsoft’s overly broad court order. I’m sure MSFT could have just worked with No-IPs abuse team and taken down only the offending domains - but I’m not going to get into rant about that.
So, I did what any self-respecting hacker does in this situation and decided to roll my own. I was already familiar with Amazon’s Route53 service so I figured why not? They have a nice REST API with granular access controls, as well as a command-line client that makes interacting with said API a breeze.
Update: AWS now sends email using a Mail-From domain that they own and control (see here). This means you don’t really need to configure your own SPF records at all. I’m leaving this post here for posterity and all the links that already point at it.
The Sender Policy Framework (SPF) is an attempt to mitigate certain types of spam - specifically spam where the sender masquerades as a different sender. Technically, you can put whatever you want in the From: header of an email message, so you can pretend to be sending emails from facebook.com simply by putting something like From: email@example.com in your email’s headers.
Email relay servers prevent this by looking up the sender’s domain’s SPF record (defined in DNS records). The SPF record tells the mail server “here are some originating IP addresses that are legit, if a message arrives pretending to be from this domain, make sure the originating IP address is on this list”.