Posts tagged hosting

Selected (belated, extended) Saturday Links

The past two weeks haven’t really left time to compile my selected links, though there have been many. A few days at SxSWi (on which more, later) followed by travelling with the family and the inevitable work backlog moved blogging way down the priority list. So here’s a mammoth selection to get me caught up. Particularly interesting has been the discussion around the future of newspapers (represented here by Clay Shirky, Steven Johnson and Russell Davies), which seem to have finally pushed beyond “how t ind a good business model for papers” to looking at where the real value for society lies and how we can preserve and extend that in a changing landscape.

Selected Saturday Links

Big themes this week have mostly revolved around twitter, facebook, and openness. Some have focussed on facebook redesigning to embrace a more twitter-like “web of flow” approach, and others on the fact that they’re jumping on various open web bandwagons. It’s been interesting to see some tie in with the government transparency thinking going around, as particularly noted by Chris Messina on FactoryCity. Meanwhile there are quite a few nice new tools emerging, and I really must try heroku one of these days.

Rails Hosting Comments: 1&1

While one of the most popular posts on this blog is the instructions I wrote up for compiling and installing Ruby and Rails at 1&1, I never actually got as far as deploying a full application there. I was helping a friend admin that server and hosting a few sites there that we work on together. We’ve got a rails app or two in the works, so I wanted to be ready, but I was never entirely comfortable with the idea of hosting there.

Last week, it became very apparent that we never would deploy an app there. After some problems with their email setup, they appeared to switch off all outgoing email from the PHP apps he had hosted there without notice, and then access to the web sites became patchy, apparently due to an unscheduled change of IP address. After a phone call (in the middle of a week day) in which he was told that the server department was ‘closed’, and then no follow-up within 24 hours, it was decided that all the sites would be migrated over to a mediatemple ‘dedicated virtual’ server, which provides comparable resources, and better access, for roughly the same money.

Rails Hosting Comments: Dreamhost

I had an email the other day asking about my experiences with a particular shared hosting company (not dreamhost). I’ve worked my way through a few companies for smaller projects, and thought I’d throw some thoughts out there.

Dreamhost are one of the cheaper hosting outfits around, and seem to inspire either love or hate, depending on your experiences. Their setup for rails is apache+fcgi, which isn’t the optimal configuration, but works well enough for a low-demand application or one where a lot of content can be cached.

Initially, I had a number of problems with which server I was placed on. One was too stretched and my subversion processes were killed before I could even finish checking out my app. Another didn’t handle a combination of subversion and fastcgi properly. And another wasn’t killing off fastcgi processes at the right time, so the app was quickly spiralling out of control. It took quite a while to get all that sorted out, and support responses were often slow, but since I’ve landed on the current server it seems fairly stable.

The one ongoing problem I’ve had is that it can be hard to manually kill processes, and deploying a new version, particularly when switching from development to production, can be a painful process as you wait for the old processes to die and the new ones take their place. That’s not necessarily a huge problem, but does crimp my style when I want to get into an agile, rapid-deployment, continuous integration flow.

Overall, I’d have to say that dreamhost may be good for hobbyist sites, but if you think you’re going to attract significant traffic it’s probably worth paying for a more appropriate environment.

Installing Ruby and Rails on a 1&1 Server

One organization I do a lot of work with hosts their sites on a 1&1 Managed Server. Essentially, only their sites and applications are running on the server, but 1&1 manage all of the sysadmin work, and don’t provide root access. I have a number of misgivings about the configuration of the server, particularly the fact that the user’s root folder is also the document root for their main domain, but 1&1 have been good about keeping PHP up to date, and we don’t have to worry about being woken at 3am to fix stuck processes. Unfortunately, Ruby hasn’t been treated to the same attention as PHP and the system version is still languishing at version 1.8.1, which won’t handle rails for us.

We entered into a round of emails to try and persuade 1&1 to upgrade ruby for us, and maybe even install gem and rails system-wide, but after a number of confusing messages where it wasn’t clear whether their answers actually applied to the plan we were on (“you need a linux server for that”/”we have a linux server”, “you need a dedicated server”/”we have a dedicated server”) we gave in and I realised that if I wanted rails I’d have to install it myself.

It turned out to be a very straightforward process. Compiling ruby and gems with appropriate prefixes (./configure –prefix=/my/preferred/folder) got them in place, and from there I was able to install the rails gems. It’s important to check that your installation folder is blocked by the web server and to put a relevant .htaccess file in place if not. You don’t want a curious visitor or malicious attacker playing with your binaries. You’ll also want to add your new bin folder to your default path by editing your .bash_profile file to add a line like:

export PATH=~/usr/bin:$PATH

With that done, changing the shebang in dispatch.cgi was enough to get the application up and running using CGI, which was enough for us to start testing applications, but would quickly become too slow once those apps are in production.

FastCGI can be activated through the ‘Server Administration > Advanced Settings’ option in the control panel. I did that, and then tried to install the fcgi gem:

gem install fcgi

It installed successfully, but building the documentation threw a sequence of errors about undefined symbols. Unfortunately when I switched my .htaccess settings so that FastCGI I received an ‘application could not start properly’ error. Being short of time, and having rails frozen into my application directory, I decided to go in and edit
[APP]/vendor/rails/railties/lib/fcgi_handler.rb directly, changing

require 'fcgi'

to include the full path to my newly installed fcgi gem.

That worked, and I now have a working, fastcgi-based rails application running on the server.