Rails app redirects to wrong port?

Ran into a situation in which a rails application was redirecting to /login to force a user to log in, but the Location header said “http://site.com:8085/login”, because nginx was listening on port 8085 on that server. At first I looked to see if there was something in the application code that was doing this, or maybe some setting I could change to fix it, but came up blank. After some Googling I found the answer right in the Nginx docs (below is my slightly-modified solution that handles https urls as well):

   proxy_redirect ~^(http(s?)://[^:]+):d+(/.+)$ $1$3;

That simply removes the port number from the Location: header, so whatever kind of proxy magic you’re doing will “just work.”

Digital Ocean – First Impressions

For the past few years I’ve been hosting this site on an old desktop in my basement on my FiOS connection. This was one of the things I really liked when I switched from Cablevision to Verizon – they don’t block port 80 inbound, so I didn’t have to pay for separate hosting. My “server” was an old AMD desktop with 1 gig ram and a sata drive. It was ok; my site was slow but I was ok with that. I configured Nginx to cache the static assets which sped most things up to “ok” levels but it was never fast.

This setup had a bunch of problems though, and the biggest one was power. Namely, it goes out in my house all the time. I probably have 4 or 5 brief outages each month, and my old box doesn’t come back up properly on reboot (some bios conflict with an eSATA disk I have hooked up to it). Plus, since my basement became a huge bathtub during Sandy, my site was down for about a month, but that wasn’t really a big concern at the time.

Anyway, via a “Promoted Tweet” on Twitter I found Digital Ocean, a VPS provider with rates starting at $5/month for an SSD-backed VM. They also had a promo at the time for a $10 credit, so I figured I’d give it a try.

Account creation was simple and I didn’t need to enter my CC until I actually created a server (“droplet” in their parlance). Server creation was pretty trivial: select the OS image (I chose CentOS 6.4 but they offer Ubuntu, Arch, Debian and Fedora as well), the size (512 MB ram through 16 GB), the region (San Francisco, New York, or Amsterdam), enter a hostname and your SSH pubkey. In about 60 seconds your server is ready to go, with a public IP and everything. My VM has a 20 GB disk and the base OS install was about 900 MB. I installed Apache, Nginx, MySQL and some other stuff, then dumped my WordPress DB and uploaded it to the new VM and copied the entire Apache docroot over as well. Within about 30 minutes of spinning up the VM I had everything up on the new box, and I made the DNS changes shortly after that. Pretty straightforward.

It’s only been a couple of days but so far I’m really liking the performance. My site doesn’t get a lot of traffic to begin with, but since I cache most stuff to disk, and the disk is SSD, it’s really quick. I’ll keep an eye on it but so far this is looking like a great choice for small website hosting. The only thing is I’ll need to setup some sort of offsite backups, but I can just cron an rsync to my home machine for now.

evanhoffman_digitalocean

Using Nginx as a caching proxy in front of WordPress

When I first started monkeying around with Nginx about a year ago, I approached it as a typical Apache fanboy. I’ve used Apache for 10+ years and it’s been a champ most of the time. Anyone familiar with Apache knows that you can do just about anything with it. It’s really the Swiss-army knife of webservers.
Continue reading Using Nginx as a caching proxy in front of WordPress

Load balancing in EC2 with Nginx and HAProxy

We wanted to setup a loadbalanced web cluster in AWS for expansion. My first inclination was to use ELB for this, but I soon learned that ELB doesn’t let you allocate a static IP, requiring you to refer to it only by DNS name. This would be OK except for the fact that our current DNS provider, Dyn, requires IP addresses when using their GSLB (geo-based load balancer) service.

Rather than let this derail the whole project, I decided to look into the software options available for loadbalancing in EC2. I’ve been a fan of hardware load balancers for a while, sort of looking down at software-based solutions without any real rationale, but in this case I really had no choice so I figured I’d give it a try.

My first stop was Nginx. I’ve used it before in a reverse-proxy scenario and like it. The problem I had with it was that it doesn’t support active polling of nodes – the ability to send requests to the webserver and mark the node as up or down based on the response. As far as I can tell, using multiple upstream servers in Nginx allows you to specify max_fails and fail_timeout, however a “fail” is determined when a real request comes in. I don’t want to risk losing a real request – I like active polling.
Continue reading Load balancing in EC2 with Nginx and HAProxy

Making sure SSLv2 is disabled in Apache (and Nginx)


Edit Jan 24, 2012: Deleted all the crap from this story and just left the recommended Apache and Nginx SSL cipher suites for maximum security without SSLv2 and without BEAST vulnerability (at least according to Qualys).

Apache httpd

SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM;
SSLHonorCipherOrder on

nginx

        ssl_protocols  SSLv3 TLSv1;
        ssl_ciphers     ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM;
        ssl_prefer_server_ciphers   on;

Source:

Go Daddy $12.99 SSL Sale!