I have a rails app which I develop on Windows with Rails 2.3.5, using sqlite3 as my database engine, and the internal Mongrel server as my webserver.
I deploy this app to a hosted Linux machine running Rails 2.1.0, using Postgres as my database, and Apache (calling dispatch.cgi) as my webserver. I do not have permissions to update the native Ruby or Rails installations, or to install gems natively.
In order to make my deployment easier (I thought...), I have taken a branch of my code-base for the deployed system. On this branch, I have updated database.yml to refer to postgres and run rake rails:freeze:gems and rake gems:unpack:dependencies. I have then exported this branch to my production server.
When I try to view my app on the production server, I get the error:
Application error
Rails application failed to start properly"
Checking the Apache error logs, I see the following:
./../config/../vendor/rails/railties/lib/initializer.rb:271:in `require_frameworks': Could not find RubyGem rack (~> 1.0.1) (RuntimeError)
from ./../config/../vendor/rails/railties/lib/initializer.rb:134:in `process'
from ./../config/../vendor/rails/railties/lib/initializer.rb:113:in `send'
from ./../config/../vendor/rails/railties/lib/initializer.rb:113:in `run'
from ./../config/environment.rb:9
from dispatch.cgi:5:in `require'
from dispatch.cgi:5
I'm confused. If Rack is required, why wasn't it included by gems:unpack? How can I get this working?
(If it's relevant, vendor$ find . -name rack* gives the following:
./rails/railties/lib/rails/rack
./rails/railties/lib/rails/rack.rb
./rails/railties/lib/rails/.svn/text-base/rack.rb.svn-base
./rails/actionpack/test/controller/rack_test.rb
./rails/actionpack/test/controller/.svn/text-base/rack_test.rb.svn-base
./rails/actionpack/lib/action_controller/rack_lint_patch.rb
./rails/actionpack/lib/action_controller/.svn/text-base/rack_lint_patch.rb.svn-base
)
Rack isn't included because it is a framework gem. To vendor this gem you can manually unpack it into vendor/gems like this:
cd vendor/gems; gem unpack rack -v="1.0.1"
You could also start using bundler to manage your dependencies, as Rails now does by default in version three to avoid problems like the one you're currently experiencing.
Your first problem is that Rails 2.1.0 does not use Rack as a middle layer.
You also need to change the rails version in the config/environment.rb file.
Also, depending on the other gems you have used, you may need to go back to a stable version that works with 2.1.0.
Personally, I would install 2.1.0 on my local machine create a new app with that rails version, copy the app folder over from the 2.3.5 project (and of course your unit tests and public folder, etc, and see if you can get it to run under 2.1.0 on your local machine, substituting gems as you go that are failing in the backtrace on the server log or in the browser. This will be much easier than running in production mode and looking at apache logs. Presuming that you have good unit tests that render all your views and flex your model code, then you should flush out any methods you have used that were added since 2.1.0 that are not supported in the older versions of Rails pretty quickly.
Related
I am working on a rails 2.3.4 application that I am trying to port over to run with IIS and Helicon Zoo. The problem I am encountering is an exception in:
c:\Zoo\Workers\ruby\lib\app.rb
where the following exception is getting raised on line ~32:
STDERR
[tid-21079944] Only Rails 2.3.x and Rails 3.x are currently supported. (RuntimeError)
C:/Zoo/Workers/ruby/lib/app.rb:33:in `build_app'
C:/Zoo/Workers/ruby/lib/app.rb:16:in `initialize'
C:/Zoo/Workers/ruby/lib/worker.rb:4:in `new'
C:/Zoo/Workers/ruby/lib/worker.rb:4:in `initialize'
C:/Zoo/Workers/ruby/zoorack.rb:30:in `new'
C:/Zoo/Workers/ruby/zoorack.rb:30
This is puzzling for me since the version of rails this application was running on previously was 2.3.4. The working hypothesis I am going on is that rails somehow can run plugins in a legacy mode? Does this make sense? I am thinking that Helicon Zoo does not support rolling back in this legacy mode prior to 2.3.4.
I hacked up the app.rb file a bit to get at the rails version.
Invoking: Rails.version.to_s
I am getting: 2.2.2
Searching the code base for '2.2.2' I see that this project depends on an actionpack lib version 2.2.2.
Further, do rails plugin versions typically follow the 'rails' version they depend on?
Is it possible to run plugins that depend on an older 'rails' version than what they run with?
The problem here was that I had installed rails 2.3.4 with gem but had copied a 2.2.2 version of rails with the project to the Helicon Zoo web root directory. The actionpack lib is part of rails. I was thinking it was a separate library.
I followed all of the directions and this is the result.
I'm in the process of creating the .rvmrc file at my application root path, as well as the setup_load_paths.rb file in my /config folder as described here. I did all that, and then I realized my computer is using ruby 1.9.3p194. While the EC instances is using 1.9.3p286. So I'm in the process of matching them up and re-creating the .rvmrc file.
While doing that, I noticed that the beanstalk ec2 server doesn't even have rails installed. I should be able to type rails --version I assume and see the version like I can on my computer and with ruby --version on the server. So I'm installing RVM, with and rails (as I've done in the past) on my new beanstalk ec2 server. But in general, it seems this all defeats the purpose. It's supposed to be somewhat automatic. Installing rails definitely doesn't sound right. Was it installed another way on the server?
Any advice on how to get the new beanstalk support for ROR working? What am I doing wrong?
From the error in your passenger exception it looks like Bundler was unable to locate the Ascii85 gem in your remote sources. Your remote source should be listed in your Gemfile at the top line in the form:
source :rubygems
If this is not working, try specifying the source explicitly in the form:
source 'http://rubygems.org'
Note that you should not be doing anything special for RVM/Passenger integration in a deploy. In fact, any extra specialized integration may actually cause problems with Elastic Beanstalk if any platform details change. You should be building your application using standard Rails conventions.
As far as rails -v failing: Rails is brought in via your Gemfile, which relies on bundle install succeeding. Your passenger error shows that Bundler failed to resolve your dependencies against your remote sources, which likely means that Rails was also not installed. In other words, Rails will only be available if the bundle installation succeeds.
My Rails 2.3.x application is failing, because it's using the wrong version of Rack (one with a bug). There are two versions of Rack on my system, a vendored one (the right version) and a system one, installed via apt-get.
Why is it using the wrong version? This is particularly puzzling me because the vendored version is being correctly used earlier in the call stack. And how I can make it use the right version?
Here's an excerpt from the stack trace I'm getting when the application fails:
/usr/lib/ruby/vendor_ruby/rack/utils.rb:202:in `set_cookie_header!'
/home/alaveteli/vendor/gems/rack-1.1.0/lib/rack/response.rb:57:in `set_cookie'
/home/alaveteli/vendor/rails/actionpack/lib/action_controller/response.rb:181:in `set_cookie'
Note that line 2 is using the vendored Rack, but line 1 is using the system Rack. (Line 57 of response.rb calls a module from Rack, thus: Utils.set_cookie_header!(header, key, value).)
My $LOAD_PATH is as I believe it should be, with the vendored gems coming before the system ones.
Yes, I am planning to migrate to using Bundler soonish.
Try using rbenv and ruby-build. It's a sane ruby version management system (unlike rvm which is insane). You get a ruby version per folder and all it's gems. When I have alaveteli issues, I usually ask them on the dev mailing list. I run the Romanian alaveteli.
At work for internal Rails applications, the server is running Rails 2.0.4 and Ruby 1.86. As far as I know, that's not going to change anytime soon and I have no control over it. I was going to try and test this out between a couple of computers and was curious if anyone knew what would happen.
Being the server is on 2.0.4, I'd like to build Rails 2.3.5 applications for that server if at all possible. From what I understand so far, it won't be a problem if I freeze gems and upack dependancies. Does that sound right?
Also, the internal work server has no gems beyond what Rails installs. What I'm wondering is, if I can successfully run a 2.3.5 application on the 2.0.4 server, can I also use extra gems and unpack those to use even though the server doesn't have them? I know that it was version 2.1 that introduced Gem Dependencies so would a 2.3.5 Rails app running on a 2.0.4 server be able to use required gems that are unpacked into an application?
One of the worst things with this situation is even if the above stuff works, the server being on 1.86 would exclude me from using a lot of really cool gems that require Ruby 1.87 (like Formtastic).
Thanks
You can manually specify the version of Rails being used in the application in the conf/environment.rb file with the RAILS_GEM_VERSION variable.
You won't be able to gems that aren't installed on your server because the application won't be able to find the libraries.
I went ahead and did the leg work to test this out. If this helps anyone else:
Rails 2.3.5 will run fine on a 2.0.x server.
With Rails 2.1 or above, you can unpack gems and your app will work on a 2.0.x server (lower version server). These are the steps I took in order. The only thing unique here is the Rack version is specific to Rails 2.3.5 (and below). In version 2.3.6 and up they switched to rack 1.1. I'm sticking to 2.3.5 because of the Rack issues with 2.3.6 and up, like broken multipart uploads).
(inside your application directory).
rake rails:freeze:gems
rake gems:unpack:dependencies
(Create a Gems Folder in the vendor folder if it's not there)
(Navigate inside the gems folder: your_app\vendor\gems)
gem unpack rack -v="1.0.1"
(There should now be a folder called "rack-1.0.1" inside the gem folder)
(Navigate back out to your application root folder)
rake gems:refresh_specs
I tested this out using the authlogic gem - moving the project over to a spare laptop that only had Rails 2.0.4 installed and no other gems (except MySQL and Mongrel). The only thing I'm not sure about yet is if a gem that requires a script file be run for installation after the gem file (like Simple Forms) will work. I'm going to test that out next when I get time.
says if i develop a Ruby on Rails application using Rails 2.3.2, will that usually be compatible with Passenger on my hosting company?
If i ssh to my hosting company and type rails -v, i get 2.2.2... so looks like they might be using Rails 2.2.2.
So if i develop a Rails app on my Macbook and ftp all files over there, will the Passenger there usually work well with the generated code with the current version of Rails?
Freeze rails into vendor/rails using the built in rake task. That way your app will ue the version of rails you want it to no matter where you deploy it.
rake rails:freeze:gems
And the easiest way to do a specific version I know of.
rake rails:freeze:edge RELEASE=2.3.2.1
Now your version of rails will go with you where you send your app.
You can unpack other gem dependencies into vendor/gems for any gem you are using and want to be sure that it is available where ever you deploy the application.
rake gems:unpack
And to ensure their dependencies go to:
rake gems:unpack:dependencies
I would also suggest that you verify that they are running the latest version of passenger.
I would verify the version of Passenger they have installed (or confirm they have it installed at all). I would also suggest you freeze your version of Rails.
Just second something for railsninja's answer .
First say, it won't work straightaway.
Is that host a vps to you or have sudo access somehow?
If yes, I suggest you to do rake gems:install instead of gems:unpack, because some of gems are os dependent e.g (Rcov, RedCloth...etc.)
I will ask the hosting company of their passenger's configuration, the important question will be if they use RailsSpawnMethod: smart or smart-lv2(default).If they use the smart method, then it is a better idea to freeze your gems and rails otherwise will have the compatible issue as you can find reference from passenger user manual about the RailsSpawnMethod.
It will be nearly 100% compatible if you freeze your gems(all the gems need to be declared correctly in the environment.rb with config.gem, e.g(config.gem 'will_paginate',:source=>"http://gems.github.com")) and RAILS!!!!!