Ruby on Rails | Screencasts | Download | Documentation | Weblog | Community | Source

Ticket #2942 (closed defect: wontfix)

Opened 3 years ago

Last modified 1 year ago

Initializer.rb not symlink savvy

Reported by: nbpwie102@sneakemail.com Assigned to: David
Priority: high Milestone:
Component: Railties Version: 1.2.1
Severity: normal Keywords:
Cc:

Description

Having followed every instruction on every 13 year old's blogiwikilivejournal within Google's reach, I have yet to come across any method of running multiple Rails applications from a single domain under Apache that actually works with the current version.

If I create a symlink to the application's public directory within my document root and add a RewriteBase directive to its .htaccess file, dispatch.cgi runs just fine, but I am still ultimately treated to a nebulous 500 error, as initializer.rb isn't smart enough to realize that it's running in a different directory, and goes searching in the document root via ".." for /config/environments/development.rb etc. I have a feeling that the commented example Alias directive in the .htaccess file might resolve this issue, but users on shared servers do not have access to their own httpd.conf files, so it's not really a viable option since the directive is not legal anywhere in an .htaccess file that I know of.

This may or may not be a bug, but if there is a simple configuration related resolution for the problem that does not require administrative access, I could not find it documented anywhere. Seeing as how this seems to be an incredibly common problem a lot of people are having, there should be some notes in environment.rb pertaining to the issue at the very least.

It's also annoying that the application seems to be pulling Rails from the gems installation despite the fact that I explicitly "froze" the gems into the vendor directory for debugging purposes. 

/usr/local/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/initializer.rb:150:in `read': No such file or directory - /Users/username/Sites/config/environments/development.rb (Errno::ENOENT)
        from /usr/local/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/initializer.rb:150:in `load_environment'
        from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.2.3/lib/active_support/core_ext/kernel.rb:27:in `silence_warnings'
        from /usr/local/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/initializer.rb:147:in `load_environment'
        from /usr/local/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/initializer.rb:78:in `process'
        from /usr/local/lib/ruby/gems/1.8/gems/rails-0.14.3/lib/initializer.rb:40:in `run'
        from /Users/username/Sites/depotpub/../config/environment.rb:10
        from /Users/username/Sites/depotpub/dispatch.cgi:3
[Fri Nov 18 14:30:50 2005] [error] [client 127.0.0.1] Premature end of script headers: /Users/username/Sites/depotpub/dispatch.cgi

Change History

11/19/05 00:20:42 changed by anonymous

After poking through the code, it seems as though defining RAILS_ROOT before boot.rb gets a chance to fixes everything. This could easily be added to the existing comments in environment.rb and save a lot of people a lot of time.

11/20/05 13:24:07 changed by anonymous

Or, even easier, pass true to Pathname#cleanpath on line 5 of boot.rb and no extra configuration is necessary.

02/22/06 05:42:32 changed by anonymous

Wow, what a major regression. And no obvious movement in three months.

03/13/06 15:13:33 changed by anonymous

Yeah, why fix serious usage and optimization problems that undermine the efficacy of your highly overrated framework when you could be showboating the greatness of your newest and most useless boutique feature and/or interview by a teenage blogger no one has ever heard of in which you really "stick it to the man" with your in-your-face attitude toward software engineers who've been writing better software than you for decades on a chatroom instead?

03/26/06 00:44:14 changed by chris.stiles@gmail.com

  • priority changed from normal to high.

Neither setting RAILS_ROOT in config/boot.rb or passing true to Pathname#cleanpath (it's done already) works.

04/11/06 06:18:28 changed by rory.hart@lifestylemange.com

  • version changed from 0.14.3 to 1.1.1.

I found by setting RAILS_ROOT in foo/public/dispatch.cgi (or .fcgi depending on your system) to the true full path i.e RAILS_ROOT = "/var/www/rails/foo/public" it works fine. I set up an alias in the httpd.conf file like so: 

Alias /foo/ "/var/www/rails/foo/public"

<Directory "/var/www/rails/foo/public/">
  AllowOverride All
  Allow from all
  Order allow,deny
  Options Indexes FollowSymLinks
</Directory>

Also set this in the .htaccess file in foo/public 

RewriteBase /foo

Of course this isn't really fixing the problem as this setup isn't a symlink but I hope it helps someone :/

(in reply to: ↑ description ) 02/20/07 21:43:13 changed by hkjolhede

  • version changed from 1.1.1 to 1.2.1.

Changing line 8 of boot.rb from 

root_path = Pathname.new(root_path).cleanpath(true).to_s

to 

root_path = Pathname.new(root_path).realpath.to_s

should do the trick. I have done some limited testing, and it seems to work, but I haven't tested it in a production environment.

05/24/07 20:04:59 changed by josh

  • status changed from new to closed.
  • resolution set to wontfix.

Sounds like a good work around, closing...