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.
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.
Increased instance sizes on AWS of course come with a higher price tag, but depending on what you need them for, the increased performance could pay for itself.
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: firstname.lastname@example.org in your email’s headers.
If you’re running a high-availability system of some kind, chances are you are into some sort of Load Balancing. If you happen to be writing a Java app, and happen to be using Apache Tomcat as your servlet container, then this tip is for you.
I had a system which needed to be HTTPS-only but also have the SSL terminated at the load balancer. Naturally, I forwarded the HTTP and HTTPS ports on my Elastic Load Balancer and had my application configured to redirect any insecure connections to an SSL connection. I started having a couple of strange issues where occasionally it would leave the connection on HTTP when it should have been redirecting.
My setup was basically:
HTTP (80) -----> ELB -----> Tomcat (8080) HTTPS (443) -----> ELB -----> Tomcat (8080)
Turned out, I needed to set a couple of extra options in my Tomcat HTTP Connector section (find it in
server.xml). This was the combination of options that did it for me: