In article 1e6901c2b46d$40ee4ff0$6501a8c0@hostpc, Joe Mack wrote:
I’m a webhost trying to get RUBY installed for a client. I’ve installed
RUBY as:
[root@ensim1 extrarpms]# ruby --version
ruby 1.6.8 (2002-12-24) [i686-linux]
[root@ensim1 extrarpms]# which ruby
/usr/local/bin/ruby
This is an ENSIM server, and the client is in a CHROOTed environment.
I asked him to test it out, and he responded: “when I try to run ruby =
from
the command line when I’m logged in as this user, I can’t see ruby, and =
I’m
not allowed to run an ls on the /usr/local/bin directory.”
Try an “ls -ld /usr/local/bin”. The permissions section of the output
(at the far left), should look like “drwxr-xr-x”, meaning that everyone
has read and execute permission to the directory. If it doesn’t, then a
“chmod 755 /usr/local/bin” may help. I say “may” because there are
probably other issues with a chrooted environment which a simple
permissions change won’t fix. If the “chmod” lets your client see and
execute the ruby executable, then you will still probably need to do the
same thing to the /usr/local/lib directory, so that the ruby executable
can see its own libraries.
Otherwise, you might want to try re-installing ruby, this time doing
“./configure --with-prefix=/usr;make;make install”. This will install
the ruby binary into /usr/bin, which, according to your site, is where
you have the perl and php binaries. If you do this, you’ll want to go
and manually remove the old ruby binary from /usr/local/bin, and the
ruby/ directory from /usr/local/lib.
mod_ruby is an embedded ruby interpreter for use with Apache. Like
mod_perl and mod_php (the latter of which is the customary way to run
php), it can provide a pretty good speedup over using a standalone
interpreter for every ruby script request. Your client will probably be
just as happy to have the normal, standalone, ruby interpreter
installed, but you may want to look into mod_ruby if performance becomes
an issue.