• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Ruby on Rails - WORKING

Z

zero@

Guest
This is how I got Ruby on Rails (RoR) working on my Plesk machine. I didn't find any major problems with Plesk's implementation, although it took me about 6 hours of trial-and-error to get it working right. SWSoft - you could seriously use some documentation for each Operating System you support.

My OS: Debian stable, using the default Rails package and fcgid. In this entry, I will try to remember everything I did to get it working. I may forget something. Your system may be different than mine. You may use yum instead of apt-get. All I know is what I know (which is not much), but I will try to help out anyone who needs help. Hopefully others will join in.

Before we begin, some warnings: I am not an expert! Be careful with what I show you here. I may be completely off-base, and if I am, please feel free to tell me. The instructions are Debian-centric, so you may have things installed in different places. Line numbers that I give below might be different on your machines, or in future versions of Rails, so use your best judgment when making changes.

Also, VERY important: It is NEVER good practice to create applications directly on your server! You should do development on a local development server, or your own workstation, and then transfer it to your server when you are fairly certain that it works and is secure. Any Rails application that I show below should NOT, under any circumstance, be left on your server for anything other than testing.

In these instructions, I try to be as generic as possible. Anything inside {brackets} should be changed to your own personal settings.

First thing's first: In your Plesk control panel, make sure that you have your server updated with Ruby On Rails is installed. To do so, go to Server > Updater and enable "Ruby on Rails Support."

After this, go to your domain, and enable FastCGI, which will allow your site to use RoR.

Open up a terminal, log in to your server. First, let's make sure that we have the important parts installed:

Code:
apt-get install ruby-rails ruby ruby1.8 ruby-activesupport psa-rubyrails-configurator

Now let's make sure that we have the correct version of FastCGI installed. We want to use mod-fcgid rather than mod-fastcgi.

Code:
apt-get remove libapache2-mod-fastcgi --purge
apt-get install libapache2-mod-fcgid psa-mod-fcgid-configurator

There may be some packages I'm forgetting. Originally, for some reason my machine had everything installed, but I had ruby1.8, and not the basic "ruby" package (which just points to ruby 1.8, I think). So every time the application called for "/usr/bin/env ruby" it couldn't use it. That might have been my screw-up, but I don't think it was. Anyway, just FYI.


Change to your httpdocs directory:

Code:
cd /var/www/vhosts/{domainname.com}/httpdocs

Create a basic rails application. To do so, use this command:

Code:
rails {railsapp}

Remember to replace {railsapp} with the name of your application.

Change the file ownership to the domains user/group:

Code:
chown {user}:{group} {railsapp}

Change the permissions on the sessions directory:

Code:
chmod 777 {railsapp}/tmp/sessions

Note: Someone let me know if this is a bad idea ... I don't think it is, but I'm not sure. My system had problems writing to the sessions folder unless I chmod'd 777.

Change directory to your new application and edit your .htaccess file in the public/ directory:

Code:
nano {railsapp}/public/.htaccess

On line 2, change:
Code:
AddHandler fastcgi-script .fcgi
To:
Code:
AddHandler fcgid-script .fcgi

On line 32, change:
Code:
RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
To:
Code:
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]


Test your installation. Go to http://www.{domainname.com}/{railsapp}/public/

You should see the standard "Welcome Aboard" Rails index page. If you click "About Your Application's Environment," you will see an error. It should read:

"Application error
Rails application failed to start properly"

Note: This error occurs because Rails 1.1.6 (the version of Rails installed by default on Plesk systems), is stable, and not cutting edge. It was an emergency security release, and this part of the application did not work. This is a known issue, and not a big one. It will not be fixed in Rails 1.1.6. You'll have to install the most up-to-date version manually (probably via gem) to get this working, and it's not worth it for the purposes of just getting Rails working.

Now, let's edit the configuration for fcgid:

Code:
nano /etc/apache2/mods-available/fcgid.conf

Code:
<IfModule mod_fcgid.c>
	  AddHandler fcgid-script .fcgi
	  SocketPath /var/lib/apache2/fcgid/sock
	  DefaultInitEnv  RAILS_ENV production
	  IdleTimeout 600
	  ProcessLifeTime 3600
	  MaxProcessCount 8
	  DefaultMaxClassProcessCount 3
	  IPCConnectTimeout 8
	  IPCCommTimeout 48
	</IfModule>

Take note to make sure that the SocketPath is pointing to the right place. You configuration should already point to the right place, so don't change anything that doesn't need to be changed! Anything that is missing from your configuration that is listed here, add to your configuration.

I'm sure that you can add these config items to each vhost.conf file, but for my purposes, it's not important to do so because I don't use fcgid for anything other than Rails on this server. So I'll just add it to the main config.


Make sure that the fcgid module is enabled:

Code:
a2enmod fcgid

Restart apache2:

Code:
apache2ctl graceful


Now let's create an actual application for testing. It's relatively simple and fast. First, you need to go back into your Plesk control panel, and create a blank mySQL database for your domain, and a new user and password for that database. Edit your new application's database configuration with these new settings. Let's change the "Production" settings for now:

Code:
nano {railsapp}/config/database.yml
Code:
	production:
	  adapter: mysql
	  database: {database_name}
	  username: {database_username}
	  password: {database_userpassword}
	  host: localhost

Again, this is just for testing. Normally you would have settings for development, test & production.

Now let's change your app's environment variables.

Code:
nano {railsapp}/config/environment.rb

Add this around the top few lines:

Code:
ENV['RAILS_ENV'] = "production"
RAILS_ENV  = ENV['RAILS_ENV']

Restart apache2:

Code:
apache2ctl graceful


This example is from the excellent book Rails Cookbook from O'Reilly. This is from the first few pages. It is an excellent book, and my tutorial will do it no justice :)

Instead of creating database tables by hand, make sure you are in your {railsapp} directory and use this command:

Code:
script/generate migration build_db

You may have to add 'ruby' to the beginning of that line, but probably now. That created a file in db/migrate named 001_build_db.rb . Let's edit this file, and change it to the following:
Code:
class BuildDb < ActiveRecord::Migration

  def self.up
    create_table :languages, :force => true do |t|
      t.column :name, :string
      t.column :description, :string
    end
  end

  def self.down
    drop_table :languages
  end
end

Run the following command to build the table:

rake db:migrate

The language table is built! We are creating a simple language application to list languages and their descriptions. Now we just need to use scaffolding to create the application. That's easy:

Code:
script/generate scaffold language

Now let's boot up WEBrick and see if the app is working

Code:
script/server

Go to your app: http://www.{domainname.com}:3000/languages/

It should be working! Now stop WEBrick using Control-C, and go to your application here:

http://www.{domainname.com}/{railsapp}/public/languages/

That's it for now. See if these help, and post if you experience any issues. Be sure to check your application's error log (in log/production.log), apache2's error log (/var/log/apache2/error_log), and your domain's error log if it doesn't show up.
 
Wow - that was LONG! I hope I helped someone :)

Here's some information on getting the app to show up as your domain's root.

EDIT: First thing's first: delete the index.html file in your app's public/ directory.

To make the app show up at the document root, we have to create a vhost.conf file in your domain's conf directory, and then use the websrvmng application to regenerate your domain's configuration.

Change directory to the domain's conf directory:
Code:
cd /var/www/vhosts/{domainname.com}/conf/

Create and begin editing a vhost.com file:
Code:
touch vhost.conf
nano vhost.conf

Add the following line, replacing data in brackets:
Code:
DocumentRoot /var/www/vhosts/{domainname.com}/httpdocs/{railsapp}/public

Reconfigure the virtualhost using websrvmng:

Code:
/usr/local/psa/admin/sbin/websrvmng -u --vhost-name={domainname.com}

Verify that the following line is in /var/www/vhosts/{domainname.com}/conf/httpd.include (usually at the bottom):

Code:
Include /var/www/vhosts/{domainname.com}/conf/vhost.conf

Restart apache:

Code:
apache2ctl graceful

Visit your site:

Code:
http://www.{domainname.com}
 
-bash-3.1$ script/generate migration build_db
/usr/lib/ruby/site_ruby/1.8/active_support/ordered_options.rb:28: superclass mismatch for class OrderedOptions (TypeError)
from /usr/lib/ruby/site_ruby/1.8/active_support/dependencies.rb:496:in `require'
from /usr/lib/ruby/site_ruby/1.8/active_support/dependencies.rb:496:in `require'
from /usr/lib/ruby/site_ruby/1.8/active_support/dependencies.rb:343:in `new_constants_in'
from /usr/lib/ruby/site_ruby/1.8/active_support/dependencies.rb:496:in `require'
from /usr/lib/ruby/site_ruby/1.8/active_support.rb:37
from /usr/lib/ruby/site_ruby/1.8/active_record.rb:30:in `require'
from /usr/lib/ruby/site_ruby/1.8/active_record.rb:30
from /usr/lib/ruby/site_ruby/1.8/initializer.rb:137:in `require'
... 7 levels...
from /usr/lib/ruby/site_ruby/1.8/commands/generate.rb:1:in `require'
from /usr/lib/ruby/site_ruby/1.8/commands/generate.rb:1
from script/generate:3:in `require'




Fedora Core 5 / Plesk 8.1

??
 
This error is usually caused by having a class with that particular name. It may be something in my instructions - I'll take a look over them.

You may have to prepend the migration command with ruby, so:

Code:
ruby script/generate migration build_db

I don't know if that would cause a problem or not.

Try this command:

Code:
rails -v

It should return something like "Rails 1.1.6"

Make sure that the version listed in {railsapp}/config/environment.rb is the same. For instance:

Code:
RAILS_GEM_VERSION = '1.1.6'
 
Also, looking at your errors, it may be that ruby may not be set up correctly. Try this in your rails app:

Code:
more script/generate

It should return something like:

Code:
#!/usr/bin/env ruby
require File.dirname(__FILE__) + '/../config/boot'
require 'commands/generate'

Make sure that the environment on the first line is valid.
 
OK, this is killing me.

I tried to get Rails to work using the mod-fcgid setup detailed above. But it just won't work on our FC4/Plesk 8.1 box.

In the fcgid crash log, I get nothing. In the domain httpd error log, I get complaints about "premature end of script headers" with no further information.

Supposedly, there is a "Rails Configurator" installed in our Plesk 8.1 build but I can't find anything at all in the web interface that has anything to do with rails beyond the entry listed in the upgrade manager components listing.

Any help is greatly appreciated.
 
Also, some notes that may help out:
  • Don't use tabs in any of these config files, if possible. Try using spaces instead.
  • Make sure that public/dispatch.fcgi has permissions of 755
  • make sure that dispatch.fcgi has no end of file (eof) characters. I think that you can get rid of them by just opening up the file, deleting the last blank lines and then hit backspace to remove any hidden characters
  • Check the "shebang" line of dispatch.fcgi. Make sure it is looking in the right location. User this command to find yours:
    Code:
    whereis ruby
    Mine reads:
    Code:
    #!/usr/bin/ruby1.8

    Yours may be "/usr/local/bin/ruby" or something similar.

Hopefully something will work :-/
 
OK, I am really a Rails newbie, and I have to say the state of documentation on this stuff is really pretty bad (just a comment, not a dig at anyone here).

I am trying to set this up for somebody else who is not a Linux person.

This is for an existing application that was developed on a Windows platform but is now being moved. I had to change a lot of the shebang lines in the scripts to point to my installation at /usr/bin/ruby

I have imported the database tables to the appropriate db in mysql and have done the configuration for the database locations in config/database.yml

If I try to run dispatch.fcgi from the command line, I get:

: bad interpreter: No such file or directory


This is what I am getting from the development.log file (but only if I run /usr/bin/ruby dispatch.fcgi from the command line, not when I access from the web server):

Recognition failed for ""
/usr/lib/ruby/site_ruby/1.8/action_controller/routing.rb:522:in `recognition_failed'
/usr/lib/ruby/site_ruby/1.8/action_controller/routing.rb:512:in `recognize!'
/usr/lib/ruby/site_ruby/1.8/dispatcher.rb:38:in `dispatch'
/usr/lib/ruby/site_ruby/1.8/fcgi_handler.rb:150:in `process_request'
/usr/lib/ruby/site_ruby/1.8/fcgi_handler.rb:54:in `process!'
/usr/lib/ruby/site_ruby/1.8/fcgi.rb:606:in `each_cgi'
/usr/lib/ruby/site_ruby/1.8/fcgi_handler.rb:53:in `process!'
/usr/lib/ruby/site_ruby/1.8/fcgi_handler.rb:23:in `process!'
dispatch.fcgi:24
 
Oh... one other thing I noticed...

Rails version that is installed on the server is 1.2.2, Ruby is version 1.8.4

When I run script/about I get:

About your application's environment
Ruby version 1.8.4 (i386-linux)
RubyGems version 0.9.0
Rails version 1.1.6
Active Record version 1.14.4
Action Pack version 1.13.2
Action Web Service version 1.1.6
Action Mailer version 1.2.5
Active Support version 1.4.1
Application root /var/www/vhosts/example.org/httpdocs/fighterdb
Environment development
Database adapter mysql
 
You may want to look out for Windows line endings in the following files: .htaccess, dispatch.fcgi, dispatch.rb, & dispatch.cgi

This should remove them, but you might have to do it by hand:

Code:
perl -pi -e "s/^M//g" .htaccess
perl -pi -e "s/^M//g" dispatch.*

Read what I wrote to nulleffect re: Rails versions. Change it in environment.rb if necessary. Make sure you are checking your installed version of rails, and not your application's settings.

My instructions were mainly for getting RoR working and verifying it, not for deployment of applications that were built on another platform and in another version of RoR. That would probably take a few pages of a book :)
 
One painful piece at a time...

I got rid of the "bad interpreter" error by making sure there were no carriage-return characters in any of the application script files.

But that doesn't help much. It just eliminates one problem, I still get things like this in my development.log file:

Recognition failed for ""
/usr/lib/ruby/site_ruby/1.8/action_controller/routing.rb:522:in `recognition_failed'
/usr/lib/ruby/site_ruby/1.8/action_controller/routing.rb:512:in `recognize!'
/usr/lib/ruby/site_ruby/1.8/dispatcher.rb:38:in `dispatch'
dispatch.rb:10


And I am still getting this in my Apache error log:

[Tue Mar 13 01:23:07 2007] [error] [client xx.xx.xx.xx] Premature end of script headers: dispatch.fcgi

So what next?

I don't think this is a problem with FastCGI configuration, it also does the same thing with the dispatch.cgi file.

I'm pretty much stumped now.
 
Eliminating one problem is better than eliminating none. It seems that you REALLY put the cart in front of the horse on this one.

Recognition failed for '' - that's your problem.

Three things to look out for:

  • Permissions. Make sure every file is owned by the user and group of the domain.
    Code:
    chown your_user:your_group {railsapp}/ -R
  • Have you restarted apache2? "apache2ctl graceful" should do the trick
  • Do you have a line in config/routes.rb that maps the route for '' ? You need something that does so, for instance:

    Code:
    map.connect '', :controller => "{your_default_controller}"

How are you trying to access the site? Something like www.yoursite.com/app/public ?

Try www.yoursite.com/app/public/{controller_name} (Where {controller_name} is the name of a controller.)

Let me know if you've done these things.

If this doesn't work, I highly recommend that you try a simple example first and make sure that works, and then move on to adapting your friend's application.
 
Originally posted by Dragon93
One painful piece at a time...

I got rid of the "bad interpreter" error by making sure there were no carriage-return characters in any of the application script files.

But that doesn't help much. It just eliminates one problem, I still get things like this in my development.log file:

Recognition failed for ""
/usr/lib/ruby/site_ruby/1.8/action_controller/routing.rb:522:in `recognition_failed'
/usr/lib/ruby/site_ruby/1.8/action_controller/routing.rb:512:in `recognize!'
/usr/lib/ruby/site_ruby/1.8/dispatcher.rb:38:in `dispatch'
dispatch.rb:10


And I am still getting this in my Apache error log:

[Tue Mar 13 01:23:07 2007] [error] [client xx.xx.xx.xx] Premature end of script headers: dispatch.fcgi

So what next?

I don't think this is a problem with FastCGI configuration, it also does the same thing with the dispatch.cgi file.

I'm pretty much stumped now.

I encountered that premature error before. Uninstall fastcgi gem and install it from source. This is the link that I found http://forum.textdrive.com/viewtopic.php?pid=28331#p28331

Then I remember making a soft link on a .so file. Try installing from source first.

You really get the error 'Recognition failed for ""' if you run dispatch.fcgi in the command line.
 
From the link you provided, the last poster says:

it might have worked just by doing this:
root> /sbin/ldconfig -v

I don't know if that will prevent you from installing from source or not. Might be worth a try.
 
I went through the exercise of installing the Ruby FCGI handler from source... had to go back and install the FCGI development library first but got all of that working.

I tried the /sbin/ldconfig -v thing.

I restarted the web server.

It still does not work. I still get the premature end of script headers problem in the httpd error log.

Nothing gets logged in fastcgi.crash.log or in development.log if I try to access it through the web server (entries in those logs are only made if I try to execute it via command line).

I did try to explicitly specify the dispatch.fcgi file at the end of the URL and now it gives me this in the httpd error log:

[Tue Mar 13 22:59:15 2007] [warn] mod_fcgid: can't apply process slot for /var/www/vhosts/example.org/httpdocs/fighter/public/dispatch.fcgi
[Tue Mar 13 23:00:47 2007] [error] [client 12.99.152.3] Premature end of script headers: dispatch.fcgi

If I try to use dispatch.cgi, it still gives the premature end of script headers error.
 
Tried changing the permissions on /var/log/httpd as noted in that URL.

I no longer get the "premature end of headers" error but I am still getting the "can't apply process slot" message.

And the web server is now reporting a 503 error instead of a 500 error.


So it seems to be trying to execute it now.

FastCGI support is enabled for that domain under Plesk.

Any other ideas?
 
Awesome - sounds like it's getting there, slowly but surely!

Check out apache2's error_log and the domain's error log. There may be some new entries.

Also, make sure that you have added IPCConnectTimeout & IPCCommTimeout settings to your module configuration file. And restart apache2, of course.
 
Before I getinto the latest round... Thanks to zero for your help, I probably would have given up before now without it.


So... False alarm on the 503 error... I uninstalled the Plesk fcgid modules and had not re-installed them which is what gave me the 503.

I just reinstalled that stuff, now I am back to the premature end of script headers and a 500 error.

Also, for the record, on our system, the directory for the fcgid socket is not /var/log/httpd/fcgidsock as listed in the URL above, it is /var/lib/httpd/fcgid/sock and it (along with all its parents) has permissions of 755 and is owned by the web server user (apache). SO no help on that one.

I tried disabling FastCGI support in the Plesk CP and then re-enabling it for the domain in question.

I copied the configuration directives from fcgid.conf to my vhost.conf file.

Same old dance, the new steps don't help. Same old story. It's quite enormously frustrating and this just reconfirms my prejudice against open source software. This should not be this hard to make it work.
 
Back
Top