Archive for the ‘Hosting’ Category.

Configuring GoDaddy SSL Certificates on Nginx

There are a number of articles out there on how to install security certificates from GoDaddy on an Nginx server, but the GoDaddy process seems to have changed since those articles were published, so I thought I would jot down the process I had to follow in the hopes that someone else finds it useful.

First, it’s worth mentioning that GoDaddy has pretty cheap SSL certificates. They aren’t the greatest, they just verify the domain, but they are pretty useful for Facebook apps, which is especially important given Facebook’s recent drive to have more users access Facebook via https. This article was immensely helpful in getting me started in the right direction, but it left out 2 important steps that kept the certificate from being properly recognized.

You’ll need to break from the instructions in that article after step 2.3. When you select ‘other’ from the webserver dropdown on GoDaddy, your zip will not include the intermediary cert (whether it’s a Starfield or GoDaddy cert). You’ll need this intermediary cert, so head on over to GoDaddy’s cert repo and download either the gd_intermediate.crt (or sf_intermediate.crt if it’s a Starfield cert) and upload to your server.

Instead of running

1
cat www.mysite.com.crt gd_bundle.crt > mysite_combined.crt

Run the following (replacing your domain name and intermediate cert name as necessary):

1
cat www.mysite.com.crt gd_intermediate.crt gd_bundle.crt > mysite_combined.crt

From there, the previously cited article should get you the rest of the way… BUT, there’s one more issue. When you try restarting Nginx, you’ll likely see an error. The intermediary cert is missing a line break, so you’ll need to open up the combined cert and change this:

1
-----END CERTIFICATE----------BEGIN CERTIFICATE-----

To this:

1
2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

A few things to watch out for with Rackspace CloudSites

I was pretty excited when I first heard about Rackspace’s CloudSites product.  The prospect of infinite scaling for just $100/month seemed to good to be true (the cost at the time).  It was.

But that’s not to suggest CloudSites doesn’t have its niche.

Here are a few things to look out for.

It’s horrendously slow

We saw rendering times upward of 1.5 seconds (including database queries) on a very simple application that was rendering in .04 seconds on a relatively underpowered and overworked VPS server.  I can go into greater detail about the VPS configuration if anyone’s interested, but I’ll assume it suffices to say that for hosting any sort of moderately sophisticated database-driven application using a RAD framework, CloudSites should be avoided.  Further to this point, we ran the application from an abysmal shared hosting account (of the $4/month variety) during the same time of day, and that saw rendering times around .2 seconds.

No opcode accelerators

We typically compile PHP with APC support when building servers; no option for that on CloudSites.  No eAccelerator or XCache either.

PHP 5.2.13

This appears to be a recent update to the platform (when we first used the product, they were running 5.2.6).  Still, we much prefer running 5.3 (we currently compile 5.3.5 on our server builds).

No SSH

For smaller projects, we use bash scripts for deployment via rsync.  This allows us to set file permissions, compress CSS / JS, clear cache, and exclude unwanted files with a single command.  Not with CloudSites though.  Fire up that FTP client and don’t make a mistake!

Delicate Media Server / aggressive caching

CloudSites promotes media files (css, js, jpeg, png, etc) to a CDN.  Plan on renaming files if you make updates.  Or setting up a cache-killing solution.

Also, at a pretty inopportune time, all images mysteriously vanished from our site.  I jumped onto online chat for support — I was told the media server was down and would be restored within the hour.  An hour later, no luck.  We subsequently moved all images to a proper CDN (Amazon’s CloudFront).

Damaged databases

Not sure if we are just lucky here, but we have never had a MySQL database ‘break’… until CloudSites.  Suddenly there was a good portion of data missing from the site.  Anything that had not been cached in flat files was gone.  We promptly logged in to the provided PHPMyAdmin GUI and were told that the database had been damaged.  I crossed my fingers and clicked ‘repair’.  Fortunately it worked.  We run scheduled db extracts quite often throughout the day, so it was likely not a huge issue, but just the fact that it happened, for the first time ever, after just a week of using this platform was pretty alarming.

Lost sessions!

This was a big headache… Users reported losing sessions — they would login, browse the site, then after a moment of time, they would no longer be logged in.  Even more alarming, some users reported that they were logged in as different users!  After about 5 hours of digging, we found out that session data is not stored in your home directory, combining it with all other sessions currently being managed by that server.  Okay, makes sense (being generous), but NOWHERE was this documented!  The fix was simple.  Define the session_save_path somewhere within your application.

1
session_save_path('/mnt/datacenter/client_code/youdomain.com/web/sessions/');

This is NOT Rackspace support

Part of the reason we made the premature jump to this platform was because of our experience with Rackspace’s support team in the past.  For almost every issue above, our support technician typically left us with “I don’t know, someone will have to get back to you tomorrow”.  That’s never happened with Rackspace support before.  They will typically ride out any issue with you for as long as it takes.  I tried calling the Cloud Servers support group, but they immediately redirected the call to the CloudSites group.  At one point our technician gave us the proverbial white flag and said simply that it was a new solution, and it was not meant for complex applications.  If running a database makes an application complex…

Keeping connected to the server holding your session

One of our first test cases for CloudSites was a Facebook application.  Big mistake.  Anyone familiar with the platform knows Facebook API requests can take a while to complete, especially methods for uploading photos.  Combine that with the horrendously slow CloudSites platform, and you get 4 image upload requests taking about 30-40 seconds.  Problem is that the cookies that tell your request which server has your session data expire in 6-60 seconds (that’s verbatim what I was told; 6-60 seconds).  In order to keep connected to the server holding your session, you cannot have a request take longer than 6-60 seconds.  This required us to refactor quite a bit, sending data back to the browser at 4 second intervals during this execution, which further slowed down application response time.  Worst of all, sometimes single requests would take more than six seconds (like uploading a 45KB image… um…), and the user would be presented with a “no suitable nodes” found error message.

So what do we use CloudSites for?  It isn’t bad for very simple high traffic applications without any sort of database connectivity.  We can run simple Facebook apps off it and not have to worry about the app suddenly exploding in popularity.  But now that Amazon allows you to define index files on S3, I’m not sure there’s any good reason to keep CloudSites up and running.  Especially at $150/month.

In fairness, we have not run anything substantial on this platform for over a year now (can you blame us?!).  Perhaps they have addressed these issues, or at least communicated them to their users.  But just be very careful about putting anything even remotely important on this solution.