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

The C-System is running
- Apache 2.0.58 comming and updating with Solaris,
- Perl 5.8.8 32bit from sunfreeware.com, compiled with gcc
- Additional PMs compiled with gcc

This configuration works fine.

By contrast the D-Systems is running
- Apache 2.2.3 coming from SUNs Coolstack
- Perl 5.8.8 32bit from SUNs Coolstack, compiled with cc
- Additional PMs compiled with cc from Sunstudio IDE

This configuration works "unfine".

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. At this point it looks like a permission issue. But
why on D-System while C-System works fine without any permission changes?

Continuing work with reading data from a database on D-System failed with
database related errors. I will have to investigate them.

At this point I think about 2 causes. The Apache Webserver does something
wrong while reading files (propable?). 

Another issue is the installation process of DBD Module. I found out that
Makefile.PL on C-System found the demo_rdbms.mk build rule for oci and made
a make (test) nearly properly. Demo_rdbms.mk should be the 64 bit rule but
it's running a 32bit Perl and the application works fine. On D-System the
same procedure failed while making Oracle.so because of wrong ELF class. To
set the 32 bit build rule demo_rdbms32.mk as a Makefile parameter forces
making of Oracle.so to be succesfull. Therefor I think it's more a version
conflict than a permission issue.

Ralph Wecks
 
________________________________

B-I-T GmbH              
Beratung für Informationsmanagement und Telekommunikation       
Essener Straße 1                        D-30173 Hannover        
Telefon: +49(0)511 80 71 90-0   Telefax: +49(0)511 80 71 90-25  
________________________________


-----Ursprüngliche Nachricht-----
Von: Charles Jardine [mailto:[EMAIL PROTECTED] 
Gesendet: Freitag, 31. August 2007 10:04
An: Bruce Sears
Cc: [email protected]
Betreff: Re: dynamic lib ignored even after "found" in
"install_driver(Oracle) failed: Can't load..." cgi problem

On 30/08/07 22:51, Bruce Sears wrote:

> the last lines in red show the dreaded "install_driver(Oracle) failed: 
> Can't load" error, but further up, you can see in the first 
> highlighted line that libclntsh.so.10.1 was actually searched for at 
> the location it exists (and where it was found when the script was run 
> from the command line!), but the search continued as if it were not 
> found!  so what the heck is going on here?  i could understand if the 
> file were corrupted (though we know it is not from the command line 
> test) or possibly unusable for some reason, but shouldn't the error 
> message be something other than "not found" at least?  anyone?

It it a permissions issue? Do the permissions on the library itself, permit
the user as whom CGI scripts run to load the library? Do the permissions on
all the directories on the path to the library allow the CGI user to search
the directory?

--
Charles Jardine - Computing Service, University of Cambridge
[EMAIL PROTECTED]    Tel: +44 1223 334506, Fax: +44 1223 334679

Reply via email to