Posted: October 25th, 2010 | Author: jgeiger | Filed under: ruby, web | Tags: dreamhost, linode.com, rails 3, ruby | 1 Comment »
Use *linode.com
Email sent to Dreamhost back in August.
I’m going to make a request for this for you. Please note, it’s a significant bump from what we have right now, Rack 1.1.0, so only our rails expert can make the call, and check to make sure it won’t break anything. She’s on vacation this week, but I’ll send her a follow up email, so she can get back with you on this as soon as she’s back.
This was the response I got from Dreamhost after waiting for two months for an answer. (After I had to ask “hey, what’s up?”)
Thanks for writing. We have to be careful with the upgrade as we have a high number of dependency packages that need to go through the upgrade. It’s scheduled and being worked on, and the current estimate for the full upgrade to 3.0.1 is within a month of two. I’ll get back to you again when there is an update, but feel free to contact me if you have any more questions.
*Link includes my referral code
Posted: August 6th, 2010 | Author: jgeiger | Filed under: ruby, web | Tags: dreamhost, linode.com, passenger, rails 3 | 4 Comments »
You have already activated rack 1.1.0, but your Gemfile requires rack 1.2.1. Consider using bundle exec.
So with the impending release of Rails 3 there is a little dependency that was added. Rack 1.2.1. Dreamhost is using passenger which also requires a version of Rack. The problem is that it’s 1.1.0. I’m pretty sure it’s not going to be possible to get Rails 3 running on Dreamhost without the servers being upgraded…
If you’re a Dreamhost customer please be sure to vote this suggestion up.
Get Ready for Rails 3
Please be sure to file a support ticket as well.
For me, if this isn’t fixed within the next few weeks I plan on moving to linode.com
Posted: May 21st, 2010 | Author: jgeiger | Filed under: ruby, web | Tags: dreamhost, logrotate, rails, ruby | 3 Comments »
While Dreamhost may rotate the apache logs for you there is nothing automatic to rotate the rails production logs. This may not be an issue since you have “unlimited” disk space but it’s a good idea anyway.
You need to install logrotate since it doesn’t exist by default on the server and then place it in a location where it can be run. You also need to create the configuration file and status files. Once that is set up, you can install a cron job via the Dreamhost panel.
Now it should be rotating your application logs nightly. You can add more sites to the conf file as needed.
Posted: May 17th, 2010 | Author: jgeiger | Filed under: ruby, web | Tags: bundler, dreamhost, git, rails 3, ruby | 13 Comments »
Please check out my earlier post so you can get the whole git/capistrano setup working as well.
So I’ve been trying to get rails 3 running with bundler on Dreamhost for a while. I’ve had a few posts on here about how to do it. In the end, they didn’t work completely. I’ve sent requests into Dreamhost to upgrade rubygems to 1.3.6 so the newest versions of bundler would work. I was told ‘No’ but go to this wiki site.
I wasn’t too happy about that since the top of the page has a big warning ‘DON’T DO THIS’. If you’re here looking at this you probably have the tech knowhow to do this and realize the world won’t end when you do.
So here’s the step by step directions for how I got it working.
You can check out the original wiki instructions at http://wiki.dreamhost.com/RubyGems.
Add this to your .bashrc
This will setup your shell to use local gems installed in your .gems directory, setup the path to check there first and opt/bin as well. Next we need to install a newer version of rubygems.
This will get rubygems installed and make sure you run your version before dreamhost’s. You then install bundler and rake. These are the only two gems I install in the system as I prefer to have all of my apps use their own gem versions. Putting everything into system is a big mess and a dependency nightmare on updates.
Next we need to make sure your app is setup to use the bundler gem. You need to modify your environment.rb and boot.rb
Make sure you change the application name to your name. Really you’re only adding the single line for the GEM_PATH
I was using the suggestions in the wiki but I eventually figured out that Dreamhost wasn’t properly picking up my gems even with the changed GEM_PATH. Adding the ‘Gem.clear_paths’ to boot.rb allowed the gems to be seen. This is what finally cracked the problem.
Hopefully this works for you.
Posted: April 30th, 2010 | Author: jgeiger | Filed under: ruby, web | Tags: bundler, dreamhost, rails 3, ruby | 2 Comments »
I’ve posted before about trying to use rails 3 with bundler and dreamhost. This is now not possible. The shared servers for dreamhost use rubygems 1.3.5. In order to use the current version of bundler you need rubygems 1.3.6.
If you are a dreamhost user please make sure to vote up the install rubygems 1.3.6 suggestion from the panel (panel.dreamhost.com) For a company that has been good about supporting ruby and rails this is something that needs to get fixed ASAP.
Posted: February 8th, 2010 | Author: jgeiger | Filed under: ruby, web | Tags: bundler, capistrano, dreamhost, git, rails 3 | 1 Comment »
UPDATE: How to setup your Dreamhost shell account update available here.
Now that rails 3 has hit beta, I decided to see if I could get it running on my dreamhost account. I’m already running a few rails applications using bundler 0.8.1, so the forced upgrade to 0.9.3 (as of this writing) is actually a point of pain, since both versions cannot co-exist.
If you’re not running an old version of bundler, this should be an easy update. If you are, it gets complicated to the point that for now, it’s not worth updating since bundler 0.9.3 still seems to have issues with rails 2.3.x.
The first thing I did was to install the bundler gem in your usual location for dreamhost. This isn’t going to be a “how do I set up rails and custom gems for dreamhost?” post as those resources exist on the web already.
On dreamhost:
gem install bundler
Now you want to setup your rails 3 application, get it into a git repository and push it there. The main point of this post is to include my deploy files which are based on the github ‘git’ deploy strategy, which is really nice. I’ve added in some code for jammit as my asset packager, and some custom bundler callbacks.
I’ve included a gist below with my deploy code. Make sure the files are in the proper directories.
Posted: February 18th, 2009 | Author: jgeiger | Filed under: ruby | Tags: capistrano, dreamhost, git, merb | 1 Comment »
I’ve been trying to use merb a bit more just to get prepared for the forthcoming rails/merb merger.
For what I’ve been doing, dreamhost has been really nice. Shell login, unlimited domains/transfer/storage with the ability to compile your own software has been a really nice thing for a low cost provider.
For this to work, you need to install git on your dreamhost account.
Nice step by step walkthrough
Official Wiki Entry
I’m not going to get into the details of using git or merb, since there are resources out there already. From here I’m going to focus on the setups for capistrano, and how to set it up to deploy your merb application from a git repository on your dreamhost account.
Here is the main capistrano configuration file which lives inside the config directory of my merb application.
deploy.rb
The configure script includes the utility methods to create the shared directories, link the database.yml and unpack the merb gems.
deploy/configure.rb
Once this is setup properly, you can just type “cap deploy” and it will use the git repository setup on your dreamhost account. If you have setup SSH keys, you won’t have to type your password. (You have setup SSH keys, right?)
There is one trick that I figured out, that may or may not be a good idea. For me right now, I’m ok with doing it.
Even if you have an SSH key setup to log into your shell account, it will still end up needing to SSH into itself to check out the git repository. (This is a tradeoff for the ability to move the git repository anywhere else, such as github.com, without changing a lot of the configuration) If you don’t do this, you need to enter your password in the middle of the deploy. I just created another SSH key for the username, put it into ~/.ssh and added the id_rsa.pub into the authorized keys. The deploy now works with nothing more than “cap deploy”.