MediaWiki / Amazon ELB / CloudFlare – IP Addresses

Using an out-of-the-box MediaWiki installation in the Amazon EC2 environment behind an Elastic Load Balancer and CloudFlare as a DNS provider, every user’s IP address will show as the load balancer’s IP address.  For obvious reasons, this is not ideal, but is easy to remedy.

First, add $wgUsedPrivateIPs = true; to your LocalSettings.php if not already present.

Then, the TrustedXFF MediaWiki extension needs to be installed, and the CloudFlare IP addresses should be added to the trusted-hosts.txt document.  The extension handles the IP range syntax used by CloudFlare, so a direct copy of the IPv4 text file is sufficient.  In addition, add your elastic load balancer IP address/range so that proxy will also be whitelisted.

Edit generate.php – find the location where a “Range too big” error could be thrown.  On the line above this, change the 8192 limit to 132192.  This will ensure all CloudFlare IP addresses are added.  If you run into performance problems later, start removing the lesser-used ISPs from the bottom of the trusted-hosts.txt document.

If your server is not live, add the require_once line to your LocalSettings.php.  Then, run the generate.php script that came with the extension.

If your server is live, you will need to specify the installation location on the command line (mediawiki_directory/cache/trusted-xff.cdb by default).

The generate.php file will create a database of IP addresses that will be used as trusted proxies.  Since you added CloudFlare’s IP addresses, you should now see the actual IP address of the user.

You may consider running generate.php periodically to receive updated IP addresses.

The procedure above allows you to get the actual IP address of the user without modifying core MediaWiki code, as the CloudFlare FAQ suggests.

Read More

How Rackspace Can Turn It Around

Rackspace reported their first quarter earnings Wednesday, and the market did not like what it reported.  At market close Thursday, the stock had suffered nearly a 25% loss.  At the same time, there was some good news in that revenue is up 20%.

Hollow Developers has always been a great fan of Rackspace, and we use their cloud server products as our failover systems.  However, we were forced to other cloud server providers for our everyday hosting needs primarily due to cost.  Amazon Web Services (AWS) has the hefty weight of Amazon behind it, allowing AWS to adopt Amazon’s aggressive pricing models, undercutting prices of competitors by a fairly substantial margin.  There has always been a premium cost to do business with Rackspace, and this premium is definitely worth it for their ‘fanatical’ customer service.  However, there are some businesses that cannot afford that premium, or don’t depend on the customer service enough in order to rationalize paying the premium.  In our case, interaction with customer service is so limited that a monthly premium doesn’t make sense.

So, how does Rackspace turn things around?

First, place benchmarks on their cloud servers instead of relying on third-party websites to compare their CPUs against Amazon’s.  In our experience, AWS virtual machines don’t have the CPU horsepower that some would expect.  If Rackspace doesn’t exceed Amazon’s performance for comparably priced servers, bump up virtual machine resources until they do.  This metric is the most important for many websites that rely heavily on dynamic pages, and can become a deciding factor in choosing one service over another.  It is not immediately apparent that Rackspace’s entry-level server actually outperforms Amazon’s closest alternative when comparing CPU and price.

Second, allow more administrative actions to be performed via the Rackspace control panel.  A Scalr-like setup for auto-scaling and easier cross-region deployments would be a huge value-add to the product.  With Scalr running $100/month, some basic built-in scaling could be a deciding factor in using Rackspace versus a competitor.  Alternatively, partner with Scalr to provide some sort of discount to the service.  Rackspace customers already receive discounts at a number of other websites, and placing a cheaper Scalr monthly cost on to the table may be a deciding factor for those wanting to grow their cloud footprint.

Finally, take a page out of Amazon’s book and add a free or nearly-free tier to Cloud Servers.  Allowing people to sample the product, even for a few months, would invariably lead to some people remaining on the platform instead of seeking out competitors.  Pairing this with a Scalr partnership would make Rackspace that much more attractive.

Surely, there are other things that Rackspace could do to regain the confidence of investors, but these seem to be the most important among small businesses with small but expanding cloud footprints like ours.

* Disclaimer – Hollow Developers is a small investor, customer, and former affiliate of Rackspace.

Read More

Amazon Elastic Load Balancer on a root domain

Over the past few months, Hollow Developers has migrated servers into the Amazon EC2 environment. As part of this setup, a load balancer redirects traffic to a number of individual EC2 web server instances.  A limitation to this, however, is that Amazon’s load balancers don’t work on root domains (for example, http://hollowdevelopers.com/, no www in front).  The reason that these load balancers don’t work on root domains is because the DNS record must be a CNAME record, and not an A record.  And, root domains at most DNS providers only allow A records.

CNAME and A Records: CNAME entries allow domains to create subdomains like ‘webmail.hollowdevelopers.com’, which can act as an alternative address to something like ‘google.com/a/hollowdevelopers.com’ – the CNAME record makes that long URL at another domain easy to remember.  A records only allow IP addresses.  Amazon Load Balancers require an entry like ‘hollowdevelopers-load-balancer.ec2.amazon.com’, so a CNAME entry is required.

So, this ultimately requires websites to use ‘www’ or something similar in front of their domain, since the ‘www’ record can be a CNAME record.  As part of their sales pitch for their Route 53 DNS service, Amazon mentions that Route 53 allows you to place CNAME-type records into your root domain.  However, we have always been happy with our DNS provider, CloudFlare.  So, what is an easy way to ensure that all traffic goes through our load balancer?

On first glance, Hollow Developers was OK – our web servers automatically redirect users from the root domain to the www domain, primarily for consistency for search engine crawlers.  However, in order for this to happen, the user would have already hit our server on the root domain.  We wanted all traffic to go through the load balancer, regardless of the small number of hits that may come in through the root domain.  This is where CloudFlare’s page rules came in.

CloudFlare page rules allow website owners to write redirect rules, allowing all traffic from the root domain to redirect to the www domain.  Best of all, even free CloudFlare accounts allow a few page rules, meaning that anyone can use this trick for a free alternative to Amazon’s Route 53.  Just a few rules will get you up and running:

  • Forward http://hollowdevelopers.com/* to http://www.hollowdevelopers.com/$1
  • Forward http://hollowdevelopers.com/ to http://www.hollowdevelopers.com/

The first rule will forward all pages on the domain to the exact same page on www.  The second rule forwards the ‘naked’ root domain to the www domain.  For more information on the syntax used, consult the CloudFlare documentation on the Page Rules interface.

There are numerous alternatives to this approach – including the use of Amazon’s Route 53 DNS service.  However, we wanted to keep CloudFlare’s security and DDOS prevention features, so this was not an option we wanted to take.  Have other alternatives?  We would love to hear your comments/questions.

Read More