On 2007-09-03 19:42:10 +0200, Ralph Wecks wrote: > It looks like permission issue - but I think it is not. > > For validation purposes I installed 2 SUN Enterprises (called C- and > D-System), both with > - Solaris 10 > - Oracle 10.2.0 (Admin Client) > - DBI 1.58 > - DBD Oracle 1.19 > - our application
[C works, D doesn't. Probably irrelevant differences in installed software
snipped]
> Trying to logon to our form management's database the message "Cant't load
> Oracle.so ... libclntsh.so.10.1 not found ..." appears. But all permissions
> seemed to be sufficient. So I enabled webserver daemon's profile and logged
> in as webservd. Walking through oracle's directories I made a cat
> libclntsh.so.10.1 at .../lib32. Yery interesting content but no permission
> problem.
>
> At this point, it seems that the error message would be correct:
> - After running a chmod -R 777 on the /oracle directory the logon procedure
> works fine
> - Revoking permission with a chmod -R 755 /oracle didn't had any effect,
> logon goes on
> - After chmod -R 644 on .../lib32 logon works fine furthermore
> - Logon failed again with "libclntsh.so.10.1 not found" after running a
> chmod -R 644 on /oracle
>
> Some functions, procedures or what ever in the oracle dbm tree obviously
> needs executable rights.
You haven't written where your libraries are installed, but from /oracle
and .../lib32 I conclude that the path to libclntsh.so.10.1 is something
like /oracle/.../lib32/libclntsh.so.10.1 (probably
/oracle/app/oracle/product/client/lib32/libclntsh.so.10.1, but it
doesn't matter much what's between oracle and lib32). To access files in
a directory, a process needs execute permissions on that directory.
So by changing the permissions on /oracle to 644, you were preventing
all root processes from accessing everything below that directory. If
that works on your "C" system, then either your application is running
as root or it is really using a different oracle client installation.
Basically the same is true for .../lib32. If that directory has
permissions 644, no non-root process can access the files in it, which
means that libclntsh.so.10.1 cannot be loaded. However, if your
application was already running at the time you did the chmod, it was
already loaded and continued to work as long as it could access other
files below /oracle which it needed to open at runtime (e.g.,
tnsnames.ora).
hp
--
_ | Peter J. Holzer | If I wanted to be "academically correct",
|_|_) | Sysadmin WSR | I'd be programming in Java.
| | | [EMAIL PROTECTED] | I don't, and I'm not.
__/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users
pgpmlyu1HsOwS.pgp
Description: PGP signature
