Problems With Path

Hey All,

Im having a bizzare problem that I'm hoping someone can give me some direction on what I should be looking for to correct it.

To best explain I'm going to use PERL, but I'm 99% sure this isn't a perl problem so please don't think this is off topic.

Linux - Freebsd..

OK, I have a job that I'm doing for a company (web based application), I need to run both web application and various command line scripts so I also have a SSH account to the machine.
Just for reference, the machine is at a large ISP and its a dedicated machine.

Here is the problem.

I requested a some perl modules to be installed, which they did AND they all work via the web without any problem.

If I come in via SSH, none of the perl modules are installed
(meaning the scripts can't locate the module when doing a USE or even checking via the command line with PERL -MCGI -e 0).

It doesn't matter if you are on the web or in via the command line the paths that perl is looking for this is always the same..

So for example lets say perl is looking for modules or whatever in

/usr/perl/modules

Via the web that is what is uses and works fine..
Via SSH it tells me it can't find the modules in that same location.

The problem is when I log in via SSH no matter where I am on the file system (even at the root) when I type PWD I see:

/usr/name/home

This isn't a symlink or anything like that - fact is I don't know what the heck but perl knows the proper path for the modules is /usr/perl/modules but when I'm logged in via SSH where those modules REALLY are is
/usr/name/home/usr/perl/modules

I know this is something to do with either how the account or SSH is setup, it can't be something with perl..

Any ideas?

Thanks
-Chris

no, it´s nothing wrong with perl
your www server seems to run chroot´ed. that´s why it needs another path for the modules than when used locally.

for a "quick fix", try this:

ssh <your host>
cd /usr/name/home
chroot .

then you should have the same environment like your www server.
for leaving the chroot´ed environment, type "exit".

Thanks for the tip M - I tried this but all I get is:

prompt% chroot .
chroot: Command not found.
prompt% ./chroot .
./chroot: Command not found.

Then when I *find* chroot and try it..

matrix% /usr/sbin/chroot .
chroot: .: Operation not permitted

So is my only option to get on the ISP to correct this?

Thanks
-Chris

the man page says nothing about needing root access for using chroot() but from testing, it seems like it does

so you probably need your ISP to do it for you (setup chroot for your ssh login too, maybe give you a second login for this purpose)

you say it is a dedicated machine. do you have root access?

[edit]
also the perl man page mentions a file called "@INC" to locate the perl libraries. but i don´t know if library==module
ask the perl gurus in the perl forum about how to setup another path for the modules depending if a program is run on the console opposed to via the web server.
[/edit]

I know, isn't it soo lame - these people pay for a dedicated machine and they are not allowed root access.

I would also think that with a dedicated machine there shouldn't be any need to have all this pre-pended path stuff for any shell login as there is (and will only ever be) a single SSH account.

So far I've been pretty unhappy with everything I've seen out there and I think i'm going to convince these people to move to my ISP where things like this isn't a issue.

I also just found out that I can't relay off their SMTP server which I also find pretty strange as I'm on a machine within their network, I've never seen a ISP that wouldn't let you relay internally (I'm not a huge fan of using sendmail)..

As for @INC, I know I could get all the path names, then add the path that is causing me problems but that just seems like doing a patch instead of fixing the real problem

And as for running "chroot", can't explain that either.. The permissions are fine for me to run it.

-r-xr-xr-x 1 root wheel 3988 Nov 6 2001 chroot

Yet I get that "Operation not permitted" - Is it me or are these guys not Aces when it comes to maintaining a linux server <g>..

Thanks
-Chris