You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Bruce Johnson <jo...@Pharmacy.Arizona.EDU> on 2013/10/21 19:57:20 UTC
Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not
being recognized?
We've set a Directory directive for some perl scripts, setting a mod_perl handler:
Alias /card_access /home/allwebfiles/perl/catcard
<Directory /home/allwebfiles/perl/catcard>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
</Directory>
The %ENV variable is there, if I print the %ENV values:
LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
MOD_PERL --> mod_perl/2.0.4
MOD_PERL_API_VERSION --> 2
ORACLE_HOME --> /usr/lib/oracle/11.2/client64
PATH --> /sbin:/usr/sbin:/bin:/usr/bin
But trying to initialize a DBI database connection results in the following error:
[Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11) line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a required shared library or dll isn't installed where expected\n at /home/allwebfiles/perl/catcard/oratest.pl line 9\n
Which is precisely the error you get when LD_LIBRARY_PATH is unset or incorrect.
libocci.so.11.1 is where it's supposed to be.
[root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
total 185016
-rw-r--r-- 1 root root 368 Sep 17 2011 glogin.sql
lrwxrwxrwx 1 root root 17 May 20 12:07 libclntsh.so -> libclntsh.so.11.1
-rw-r--r-- 1 root root 52761218 Sep 17 2011 libclntsh.so.11.1
-rw-r--r-- 1 root root 7955322 Sep 17 2011 libnnz11.so
lrwxrwxrwx 1 root root 15 May 20 12:07 libocci.so -> libocci.so.11.1
-rw-r--r-- 1 root root 1971762 Sep 17 2011 libocci.so.11.1
-rw-r--r-- 1 root root 118408281 Sep 17 2011 libociei.so
-rw-r--r-- 1 root root 164836 Sep 17 2011 libocijdbc11.so
-rw-r--r-- 1 root root 1503303 Sep 17 2011 libsqlplusic.so
-rw-r--r-- 1 root root 1477446 Sep 17 2011 libsqlplus.so
-rw-r--r-- 1 root root 2095661 Sep 17 2011 ojdbc5.jar
-rw-r--r-- 1 root root 2714016 Sep 17 2011 ojdbc6.jar
-rw-r--r-- 1 root root 300666 Sep 17 2011 ottclasses.zip
-rw-r--r-- 1 root root 66779 Sep 17 2011 xstreams.jar
The path is correct, the script works fine on the command line, and if I comment out the handler directives in the perl.conf script, put in a ScriptAlias and process the script as a normal CGI script, it also works.
I'm confident the issue doesn't have anything to do with DBI or DBD::Oracle.
It ONLY fails when the script is executed as a mod_perl handler.
The script itself is very simple; all I do is create a database handle and if no error is thrown, print 'It works'.
#!/usr/bin/perl
use DBI;
use strict;
my $login="xxxxxx";
my $dbpass='xxxxxxxx';
my $dbname="host=xxx.xxx.xxx.xx;sid=xxx";
my $dbh = DBI->connect("dbi:Oracle:$dbname", $login, $dbpass, {RaiseError =>1});
print "Content-type: text/html\n\n";
print "It Works";
exit;
(and this is just a test , any script using DBI fails with this error.)
What am I missing?
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Bruce Johnson <jo...@Pharmacy.Arizona.EDU>.
On Oct 21, 2013, at 1:11 PM, Charlie Smith <Sm...@ldschurch.org> wrote:
> Try setting perl env inside apache config.
>
> Example:
>
> SetEnv PERL5LIB "/usr/lib/5.10.0: /usr/lib/additionalPerlInstallArea"
>
>
> You also should have
>
> LoadModule perl_module modules/mod_perl.so
It's there in perl.conf which is being run.
>
>
> grep for mod_perl in the Apache error_log file? you'll see line indicating that mod_perl resuming normal operations.
It's there:
Mon Oct 21 13:21:21 2013] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations
also the mod_perl version and API are in %ENV:
LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
MOD_PERL --> mod_perl/2.0.4
MOD_PERL_API_VERSION --> 2
ORACLE_HOME --> /usr/lib/oracle/11.2/client64
>
> Try also
> PerlResponseHandler ModPerl::RegistryPrefork
I get the same error.
>
> Could also try putting in a ScriptAlias directive in httpd.conf for where you perl scripts are.
If I do that, I get the error:
[root@merthiolate catcard]# service httpd restart
Stopping httpd: [ OK ]
Starting httpd: [Mon Oct 21 10:43:21 2013] [warn] The ScriptAlias directive in /etc/httpd/conf/httpd.conf at line 593 will probably never match because it overlaps an earlier Alias.
[ OK ]
>
> Make sure your perl dir is correct. There may be some aliases etc. needed from /usr/lib/localperl to /usr/lib/perl for example.
Perl is working just fine, if I don't use DBI in the script no errors happen.
>
> 64 bit perl?
>
Yes, 64-bit everything.
The script works if I comment out the mod_perl handler, uncomment the ScriptAlias line and restart Apache, so it HAS to be with the mod_perl handler directives.
>
> -----Original Message-----
> From: Bruce Johnson [mailto:johnson@Pharmacy.Arizona.EDU]
> Sent: Monday, October 21, 2013 1:46 PM
> To: Fred Moyer
> Cc: mod_perl list
> Subject: Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
>
> Right where it's supposed to:
>
> /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>
> Again, if this was missing or the build was broken, it wouldn't work on the command line or as a CGI script, either.
>
> This is what's making me go mad...I can't find anything wrong.
>
>
> %ENV is right
> %INC is right
>
> httpd.conf and perl.conf are right, as far as I can tell
>
>
> I've found one reference to this online that isn't very encouraging:
>
> <http://stackoverflow.com/questions/17050541/unable-to-use-dbdoracle-from-apache-mod-perl>
>
> "Never got to the bottom of this problem. Built different version of Apache and ModPerl and tried various combinations of Oracle client until the problem went away. Working combination: Apache/2.2.24 (Unix) mod_perl/2.0.7 Perl/v5.10.1"
>
> Our sysadmin would rather we kept to the CentOS repos for all this to make life easier for managing updates (this is a vm)
>
> On Oct 21, 2013, at 11:42 AM, Fred Moyer <fr...@redhotpenguin.com> wrote:
>
>> Where does Oracle.so live on your filesystem?
>>
>>
>> On Mon, Oct 21, 2013 at 11:37 AM, Bruce Johnson <jo...@pharmacy.arizona.edu> wrote:
>>
>> On Oct 21, 2013, at 11:20 AM, Fred Moyer <fr...@redhotpenguin.com> wrote:
>>
>>> This is annoying but it happens on 64 bit architectures.
>>>
>>>> The path is correct, the script works fine on the command line, and if I comment out the handler directives in the perl.conf script, put in a ScriptAlias and process the script as a normal CGI script, it also works.
>>>
>>> Sounds like some environment variable is not getting passed correctly to mod_perl. Maybe dump out %ENV from the command line and see if there are additional vars you need to pass?
>>
>> Nope, good idea but the vars I need are present, even with the modperl
>> handler in place. The only ones you need for DBD::Oracle to work are
>> ORACLE_HOME and LD_LIBRARY_PATH
>>
>> DBD::Oracle was properly compiled, else it wouldn't work on the command line, either.
>>
>>>
>>> I'd dump out %INC from the command line and mod_perl also to make sure that you are loading the needed modules. You could try to install DBD::Oracle in /usr/lib instead of /usr/local/lib also - my guess is that it's looking for the Oracle.so in /usr/local/lib but it is located somewhere else.
>>
>> With mod_perl there is just one more, /etc/httpd
>>
>> command line:
>>
>> INC-> /usr/local/lib64/perl5
>> INC-> /usr/local/share/perl5
>> INC-> /usr/lib64/perl5/vendor_perl
>> INC-> /usr/share/perl5/vendor_perl
>> INC-> /usr/lib64/perl5
>> INC-> /usr/share/perl5
>> INC-> .
>>
>> server:
>>
>> INC-> /usr/local/lib64/perl5
>> INC-> /usr/local/share/perl5
>> INC-> /usr/lib64/perl5/vendor_perl
>> INC-> /usr/share/perl5/vendor_perl
>> INC-> /usr/lib64/perl5
>> INC-> /usr/share/perl5
>> INC-> .
>> INC-> /etc/httpd
>>
>>
>>>
>>>
>>> On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <jo...@pharmacy.arizona.edu> wrote:
>>> We've set a Directory directive for some perl scripts, setting a mod_perl handler:
>>>
>>> Alias /card_access /home/allwebfiles/perl/catcard
>>>
>>> <Directory /home/allwebfiles/perl/catcard>
>>> SetHandler perl-script
>>> PerlResponseHandler ModPerl::Registry
>>> PerlOptions +ParseHeaders
>>> Options +ExecCGI
>>> PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
>>> PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
>>> </Directory>
>>>
>>> The %ENV variable is there, if I print the %ENV values:
>>>
>>> LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib MOD_PERL -->
>>> mod_perl/2.0.4 MOD_PERL_API_VERSION --> 2 ORACLE_HOME -->
>>> /usr/lib/oracle/11.2/client64 PATH --> /sbin:/usr/sbin:/bin:/usr/bin
>>>
>>> But trying to initialize a DBI database connection results in the following error:
>>>
>>> [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed:
>>> Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for
>>> module DBD::Oracle: libocci.so.11.1: cannot open shared object file:
>>> No such file or directory at /usr/lib64/perl5/DynaLoader.pm line
>>> 200.\n at (eval 11) line 3\nCompilation failed in require at (eval
>>> 11) line 3.\nPerhaps a required shared library or dll isn't
>>> installed where expected\n at
>>> /home/allwebfiles/perl/catcard/oratest.pl line 9\n
>>>
>>> Which is precisely the error you get when LD_LIBRARY_PATH is unset or incorrect.
>>>
>>> libocci.so.11.1 is where it's supposed to be.
>>>
>>> [root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
>>> total 185016
>>> -rw-r--r-- 1 root root 368 Sep 17 2011 glogin.sql
>>> lrwxrwxrwx 1 root root 17 May 20 12:07 libclntsh.so -> libclntsh.so.11.1
>>> -rw-r--r-- 1 root root 52761218 Sep 17 2011 libclntsh.so.11.1
>>> -rw-r--r-- 1 root root 7955322 Sep 17 2011 libnnz11.so
>>> lrwxrwxrwx 1 root root 15 May 20 12:07 libocci.so -> libocci.so.11.1
>>> -rw-r--r-- 1 root root 1971762 Sep 17 2011 libocci.so.11.1
>>> -rw-r--r-- 1 root root 118408281 Sep 17 2011 libociei.so
>>> -rw-r--r-- 1 root root 164836 Sep 17 2011 libocijdbc11.so
>>> -rw-r--r-- 1 root root 1503303 Sep 17 2011 libsqlplusic.so
>>> -rw-r--r-- 1 root root 1477446 Sep 17 2011 libsqlplus.so
>>> -rw-r--r-- 1 root root 2095661 Sep 17 2011 ojdbc5.jar
>>> -rw-r--r-- 1 root root 2714016 Sep 17 2011 ojdbc6.jar
>>> -rw-r--r-- 1 root root 300666 Sep 17 2011 ottclasses.zip
>>> -rw-r--r-- 1 root root 66779 Sep 17 2011 xstreams.jar
>>>
>>> The path is correct, the script works fine on the command line, and if I comment out the handler directives in the perl.conf script, put in a ScriptAlias and process the script as a normal CGI script, it also works.
>>>
>>> I'm confident the issue doesn't have anything to do with DBI or DBD::Oracle.
>>>
>>> It ONLY fails when the script is executed as a mod_perl handler.
>>>
>>> The script itself is very simple; all I do is create a database handle and if no error is thrown, print 'It works'.
>>>
>>> #!/usr/bin/perl
>>> use DBI;
>>> use strict;
>>>
>>> my $login="xxxxxx";
>>> my $dbpass='xxxxxxxx';
>>> my $dbname="host=xxx.xxx.xxx.xx;sid=xxx";
>>> my $dbh = DBI->connect("dbi:Oracle:$dbname", $login, $dbpass,
>>> {RaiseError =>1});
>>>
>>> print "Content-type: text/html\n\n"; print "It Works"; exit;
>>>
>>> (and this is just a test , any script using DBI fails with this
>>> error.)
>>>
>>> What am I missing?
>>>
>>> --
>>> Bruce Johnson
>>> University of Arizona
>>> College of Pharmacy
>>> Information Technology Group
>>>
>>> Institutions do not have opinions, merely customs
>>>
>>>
>>>
>>
>> --
>> Bruce Johnson
>> University of Arizona
>> College of Pharmacy
>> Information Technology Group
>>
>> Institutions do not have opinions, merely customs
>>
>>
>>
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>
> NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
>
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
RE: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Charlie Smith <Sm...@ldschurch.org>.
Try setting perl env inside apache config.
Example:
SetEnv PERL5LIB "/usr/lib/5.10.0: /usr/lib/additionalPerlInstallArea"
You also should have
LoadModule perl_module modules/mod_perl.so
grep for mod_perl in the Apache error_log file? you'll see line indicating that mod_perl resuming normal operations.
Try also
PerlResponseHandler ModPerl::RegistryPrefork
Could also try putting in a ScriptAlias directive in httpd.conf for where you perl scripts are.
Make sure your perl dir is correct. There may be some aliases etc. needed from /usr/lib/localperl to /usr/lib/perl for example.
64 bit perl?
-----Original Message-----
From: Bruce Johnson [mailto:johnson@Pharmacy.Arizona.EDU]
Sent: Monday, October 21, 2013 1:46 PM
To: Fred Moyer
Cc: mod_perl list
Subject: Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
Right where it's supposed to:
/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
Again, if this was missing or the build was broken, it wouldn't work on the command line or as a CGI script, either.
This is what's making me go mad...I can't find anything wrong.
%ENV is right
%INC is right
httpd.conf and perl.conf are right, as far as I can tell
I've found one reference to this online that isn't very encouraging:
<http://stackoverflow.com/questions/17050541/unable-to-use-dbdoracle-from-apache-mod-perl>
"Never got to the bottom of this problem. Built different version of Apache and ModPerl and tried various combinations of Oracle client until the problem went away. Working combination: Apache/2.2.24 (Unix) mod_perl/2.0.7 Perl/v5.10.1"
Our sysadmin would rather we kept to the CentOS repos for all this to make life easier for managing updates (this is a vm)
On Oct 21, 2013, at 11:42 AM, Fred Moyer <fr...@redhotpenguin.com> wrote:
> Where does Oracle.so live on your filesystem?
>
>
> On Mon, Oct 21, 2013 at 11:37 AM, Bruce Johnson <jo...@pharmacy.arizona.edu> wrote:
>
> On Oct 21, 2013, at 11:20 AM, Fred Moyer <fr...@redhotpenguin.com> wrote:
>
> > This is annoying but it happens on 64 bit architectures.
> >
> > > The path is correct, the script works fine on the command line, and if I comment out the handler directives in the perl.conf script, put in a ScriptAlias and process the script as a normal CGI script, it also works.
> >
> > Sounds like some environment variable is not getting passed correctly to mod_perl. Maybe dump out %ENV from the command line and see if there are additional vars you need to pass?
>
> Nope, good idea but the vars I need are present, even with the modperl
> handler in place. The only ones you need for DBD::Oracle to work are
> ORACLE_HOME and LD_LIBRARY_PATH
>
> DBD::Oracle was properly compiled, else it wouldn't work on the command line, either.
>
> >
> > I'd dump out %INC from the command line and mod_perl also to make sure that you are loading the needed modules. You could try to install DBD::Oracle in /usr/lib instead of /usr/local/lib also - my guess is that it's looking for the Oracle.so in /usr/local/lib but it is located somewhere else.
>
> With mod_perl there is just one more, /etc/httpd
>
> command line:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
>
> server:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
> INC-> /etc/httpd
>
>
> >
> >
> > On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <jo...@pharmacy.arizona.edu> wrote:
> > We've set a Directory directive for some perl scripts, setting a mod_perl handler:
> >
> > Alias /card_access /home/allwebfiles/perl/catcard
> >
> > <Directory /home/allwebfiles/perl/catcard>
> > SetHandler perl-script
> > PerlResponseHandler ModPerl::Registry
> > PerlOptions +ParseHeaders
> > Options +ExecCGI
> > PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
> > PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
> > </Directory>
> >
> > The %ENV variable is there, if I print the %ENV values:
> >
> > LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib MOD_PERL -->
> > mod_perl/2.0.4 MOD_PERL_API_VERSION --> 2 ORACLE_HOME -->
> > /usr/lib/oracle/11.2/client64 PATH --> /sbin:/usr/sbin:/bin:/usr/bin
> >
> > But trying to initialize a DBI database connection results in the following error:
> >
> > [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed:
> > Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for
> > module DBD::Oracle: libocci.so.11.1: cannot open shared object file:
> > No such file or directory at /usr/lib64/perl5/DynaLoader.pm line
> > 200.\n at (eval 11) line 3\nCompilation failed in require at (eval
> > 11) line 3.\nPerhaps a required shared library or dll isn't
> > installed where expected\n at
> > /home/allwebfiles/perl/catcard/oratest.pl line 9\n
> >
> > Which is precisely the error you get when LD_LIBRARY_PATH is unset or incorrect.
> >
> > libocci.so.11.1 is where it's supposed to be.
> >
> > [root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
> > total 185016
> > -rw-r--r-- 1 root root 368 Sep 17 2011 glogin.sql
> > lrwxrwxrwx 1 root root 17 May 20 12:07 libclntsh.so -> libclntsh.so.11.1
> > -rw-r--r-- 1 root root 52761218 Sep 17 2011 libclntsh.so.11.1
> > -rw-r--r-- 1 root root 7955322 Sep 17 2011 libnnz11.so
> > lrwxrwxrwx 1 root root 15 May 20 12:07 libocci.so -> libocci.so.11.1
> > -rw-r--r-- 1 root root 1971762 Sep 17 2011 libocci.so.11.1
> > -rw-r--r-- 1 root root 118408281 Sep 17 2011 libociei.so
> > -rw-r--r-- 1 root root 164836 Sep 17 2011 libocijdbc11.so
> > -rw-r--r-- 1 root root 1503303 Sep 17 2011 libsqlplusic.so
> > -rw-r--r-- 1 root root 1477446 Sep 17 2011 libsqlplus.so
> > -rw-r--r-- 1 root root 2095661 Sep 17 2011 ojdbc5.jar
> > -rw-r--r-- 1 root root 2714016 Sep 17 2011 ojdbc6.jar
> > -rw-r--r-- 1 root root 300666 Sep 17 2011 ottclasses.zip
> > -rw-r--r-- 1 root root 66779 Sep 17 2011 xstreams.jar
> >
> > The path is correct, the script works fine on the command line, and if I comment out the handler directives in the perl.conf script, put in a ScriptAlias and process the script as a normal CGI script, it also works.
> >
> > I'm confident the issue doesn't have anything to do with DBI or DBD::Oracle.
> >
> > It ONLY fails when the script is executed as a mod_perl handler.
> >
> > The script itself is very simple; all I do is create a database handle and if no error is thrown, print 'It works'.
> >
> > #!/usr/bin/perl
> > use DBI;
> > use strict;
> >
> > my $login="xxxxxx";
> > my $dbpass='xxxxxxxx';
> > my $dbname="host=xxx.xxx.xxx.xx;sid=xxx";
> > my $dbh = DBI->connect("dbi:Oracle:$dbname", $login, $dbpass,
> > {RaiseError =>1});
> >
> > print "Content-type: text/html\n\n"; print "It Works"; exit;
> >
> > (and this is just a test , any script using DBI fails with this
> > error.)
> >
> > What am I missing?
> >
> > --
> > Bruce Johnson
> > University of Arizona
> > College of Pharmacy
> > Information Technology Group
> >
> > Institutions do not have opinions, merely customs
> >
> >
> >
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Bruce Johnson <jo...@Pharmacy.Arizona.EDU>.
Right where it's supposed to:
/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
Again, if this was missing or the build was broken, it wouldn't work on the command line or as a CGI script, either.
This is what's making me go mad…I can't find anything wrong.
%ENV is right
%INC is right
httpd.conf and perl.conf are right, as far as I can tell
I've found one reference to this online that isn't very encouraging:
<http://stackoverflow.com/questions/17050541/unable-to-use-dbdoracle-from-apache-mod-perl>
"Never got to the bottom of this problem. Built different version of Apache and ModPerl and tried various combinations of Oracle client until the problem went away. Working combination: Apache/2.2.24 (Unix) mod_perl/2.0.7 Perl/v5.10.1"
Our sysadmin would rather we kept to the CentOS repos for all this to make life easier for managing updates (this is a vm)
On Oct 21, 2013, at 11:42 AM, Fred Moyer <fr...@redhotpenguin.com> wrote:
> Where does Oracle.so live on your filesystem?
>
>
> On Mon, Oct 21, 2013 at 11:37 AM, Bruce Johnson <jo...@pharmacy.arizona.edu> wrote:
>
> On Oct 21, 2013, at 11:20 AM, Fred Moyer <fr...@redhotpenguin.com> wrote:
>
> > This is annoying but it happens on 64 bit architectures.
> >
> > > The path is correct, the script works fine on the command line, and if I comment out the handler directives in the perl.conf script, put in a ScriptAlias and process the script as a normal CGI script, it also works.
> >
> > Sounds like some environment variable is not getting passed correctly to mod_perl. Maybe dump out %ENV from the command line and see if there are additional vars you need to pass?
>
> Nope, good idea but the vars I need are present, even with the modperl handler in place. The only ones you need for DBD::Oracle to work are ORACLE_HOME and LD_LIBRARY_PATH
>
> DBD::Oracle was properly compiled, else it wouldn't work on the command line, either.
>
> >
> > I'd dump out %INC from the command line and mod_perl also to make sure that you are loading the needed modules. You could try to install DBD::Oracle in /usr/lib instead of /usr/local/lib also - my guess is that it's looking for the Oracle.so in /usr/local/lib but it is located somewhere else.
>
> With mod_perl there is just one more, /etc/httpd
>
> command line:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
>
> server:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
> INC-> /etc/httpd
>
>
> >
> >
> > On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <jo...@pharmacy.arizona.edu> wrote:
> > We've set a Directory directive for some perl scripts, setting a mod_perl handler:
> >
> > Alias /card_access /home/allwebfiles/perl/catcard
> >
> > <Directory /home/allwebfiles/perl/catcard>
> > SetHandler perl-script
> > PerlResponseHandler ModPerl::Registry
> > PerlOptions +ParseHeaders
> > Options +ExecCGI
> > PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
> > PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
> > </Directory>
> >
> > The %ENV variable is there, if I print the %ENV values:
> >
> > LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
> > MOD_PERL --> mod_perl/2.0.4
> > MOD_PERL_API_VERSION --> 2
> > ORACLE_HOME --> /usr/lib/oracle/11.2/client64
> > PATH --> /sbin:/usr/sbin:/bin:/usr/bin
> >
> > But trying to initialize a DBI database connection results in the following error:
> >
> > [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11) line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a required shared library or dll isn't installed where expected\n at /home/allwebfiles/perl/catcard/oratest.pl line 9\n
> >
> > Which is precisely the error you get when LD_LIBRARY_PATH is unset or incorrect.
> >
> > libocci.so.11.1 is where it's supposed to be.
> >
> > [root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
> > total 185016
> > -rw-r--r-- 1 root root 368 Sep 17 2011 glogin.sql
> > lrwxrwxrwx 1 root root 17 May 20 12:07 libclntsh.so -> libclntsh.so.11.1
> > -rw-r--r-- 1 root root 52761218 Sep 17 2011 libclntsh.so.11.1
> > -rw-r--r-- 1 root root 7955322 Sep 17 2011 libnnz11.so
> > lrwxrwxrwx 1 root root 15 May 20 12:07 libocci.so -> libocci.so.11.1
> > -rw-r--r-- 1 root root 1971762 Sep 17 2011 libocci.so.11.1
> > -rw-r--r-- 1 root root 118408281 Sep 17 2011 libociei.so
> > -rw-r--r-- 1 root root 164836 Sep 17 2011 libocijdbc11.so
> > -rw-r--r-- 1 root root 1503303 Sep 17 2011 libsqlplusic.so
> > -rw-r--r-- 1 root root 1477446 Sep 17 2011 libsqlplus.so
> > -rw-r--r-- 1 root root 2095661 Sep 17 2011 ojdbc5.jar
> > -rw-r--r-- 1 root root 2714016 Sep 17 2011 ojdbc6.jar
> > -rw-r--r-- 1 root root 300666 Sep 17 2011 ottclasses.zip
> > -rw-r--r-- 1 root root 66779 Sep 17 2011 xstreams.jar
> >
> > The path is correct, the script works fine on the command line, and if I comment out the handler directives in the perl.conf script, put in a ScriptAlias and process the script as a normal CGI script, it also works.
> >
> > I'm confident the issue doesn't have anything to do with DBI or DBD::Oracle.
> >
> > It ONLY fails when the script is executed as a mod_perl handler.
> >
> > The script itself is very simple; all I do is create a database handle and if no error is thrown, print 'It works'.
> >
> > #!/usr/bin/perl
> > use DBI;
> > use strict;
> >
> > my $login="xxxxxx";
> > my $dbpass='xxxxxxxx';
> > my $dbname="host=xxx.xxx.xxx.xx;sid=xxx";
> > my $dbh = DBI->connect("dbi:Oracle:$dbname", $login, $dbpass, {RaiseError =>1});
> >
> > print "Content-type: text/html\n\n";
> > print "It Works";
> > exit;
> >
> > (and this is just a test , any script using DBI fails with this error.)
> >
> > What am I missing?
> >
> > --
> > Bruce Johnson
> > University of Arizona
> > College of Pharmacy
> > Information Technology Group
> >
> > Institutions do not have opinions, merely customs
> >
> >
> >
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not
being recognized?
Posted by Fred Moyer <fr...@redhotpenguin.com>.
Where does Oracle.so live on your filesystem?
On Mon, Oct 21, 2013 at 11:37 AM, Bruce Johnson <
johnson@pharmacy.arizona.edu> wrote:
>
> On Oct 21, 2013, at 11:20 AM, Fred Moyer <fr...@redhotpenguin.com> wrote:
>
> > This is annoying but it happens on 64 bit architectures.
> >
> > > The path is correct, the script works fine on the command line, and if
> I comment out the handler directives in the perl.conf script, put in a
> ScriptAlias and process the script as a normal CGI script, it also works.
> >
> > Sounds like some environment variable is not getting passed correctly to
> mod_perl. Maybe dump out %ENV from the command line and see if there are
> additional vars you need to pass?
>
> Nope, good idea but the vars I need are present, even with the modperl
> handler in place. The only ones you need for DBD::Oracle to work are
> ORACLE_HOME and LD_LIBRARY_PATH
>
> DBD::Oracle was properly compiled, else it wouldn't work on the command
> line, either.
>
> >
> > I'd dump out %INC from the command line and mod_perl also to make sure
> that you are loading the needed modules. You could try to install
> DBD::Oracle in /usr/lib instead of /usr/local/lib also - my guess is that
> it's looking for the Oracle.so in /usr/local/lib but it is located
> somewhere else.
>
> With mod_perl there is just one more, /etc/httpd
>
> command line:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
>
> server:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
> INC-> /etc/httpd
>
>
> >
> >
> > On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <
> johnson@pharmacy.arizona.edu> wrote:
> > We've set a Directory directive for some perl scripts, setting a
> mod_perl handler:
> >
> > Alias /card_access /home/allwebfiles/perl/catcard
> >
> > <Directory /home/allwebfiles/perl/catcard>
> > SetHandler perl-script
> > PerlResponseHandler ModPerl::Registry
> > PerlOptions +ParseHeaders
> > Options +ExecCGI
> > PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
> > PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
> > </Directory>
> >
> > The %ENV variable is there, if I print the %ENV values:
> >
> > LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
> > MOD_PERL --> mod_perl/2.0.4
> > MOD_PERL_API_VERSION --> 2
> > ORACLE_HOME --> /usr/lib/oracle/11.2/client64
> > PATH --> /sbin:/usr/sbin:/bin:/usr/bin
> >
> > But trying to initialize a DBI database connection results in the
> following error:
> >
> > [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't
> load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module
> DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file
> or directory at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11)
> line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a
> required shared library or dll isn't installed where expected\n at
> /home/allwebfiles/perl/catcard/oratest.pl line 9\n
> >
> > Which is precisely the error you get when LD_LIBRARY_PATH is unset or
> incorrect.
> >
> > libocci.so.11.1 is where it's supposed to be.
> >
> > [root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
> > total 185016
> > -rw-r--r-- 1 root root 368 Sep 17 2011 glogin.sql
> > lrwxrwxrwx 1 root root 17 May 20 12:07 libclntsh.so ->
> libclntsh.so.11.1
> > -rw-r--r-- 1 root root 52761218 Sep 17 2011 libclntsh.so.11.1
> > -rw-r--r-- 1 root root 7955322 Sep 17 2011 libnnz11.so
> > lrwxrwxrwx 1 root root 15 May 20 12:07 libocci.so ->
> libocci.so.11.1
> > -rw-r--r-- 1 root root 1971762 Sep 17 2011 libocci.so.11.1
> > -rw-r--r-- 1 root root 118408281 Sep 17 2011 libociei.so
> > -rw-r--r-- 1 root root 164836 Sep 17 2011 libocijdbc11.so
> > -rw-r--r-- 1 root root 1503303 Sep 17 2011 libsqlplusic.so
> > -rw-r--r-- 1 root root 1477446 Sep 17 2011 libsqlplus.so
> > -rw-r--r-- 1 root root 2095661 Sep 17 2011 ojdbc5.jar
> > -rw-r--r-- 1 root root 2714016 Sep 17 2011 ojdbc6.jar
> > -rw-r--r-- 1 root root 300666 Sep 17 2011 ottclasses.zip
> > -rw-r--r-- 1 root root 66779 Sep 17 2011 xstreams.jar
> >
> > The path is correct, the script works fine on the command line, and if I
> comment out the handler directives in the perl.conf script, put in a
> ScriptAlias and process the script as a normal CGI script, it also works.
> >
> > I'm confident the issue doesn't have anything to do with DBI or
> DBD::Oracle.
> >
> > It ONLY fails when the script is executed as a mod_perl handler.
> >
> > The script itself is very simple; all I do is create a database handle
> and if no error is thrown, print 'It works'.
> >
> > #!/usr/bin/perl
> > use DBI;
> > use strict;
> >
> > my $login="xxxxxx";
> > my $dbpass='xxxxxxxx';
> > my $dbname="host=xxx.xxx.xxx.xx;sid=xxx";
> > my $dbh = DBI->connect("dbi:Oracle:$dbname", $login, $dbpass,
> {RaiseError =>1});
> >
> > print "Content-type: text/html\n\n";
> > print "It Works";
> > exit;
> >
> > (and this is just a test , any script using DBI fails with this error.)
> >
> > What am I missing?
> >
> > --
> > Bruce Johnson
> > University of Arizona
> > College of Pharmacy
> > Information Technology Group
> >
> > Institutions do not have opinions, merely customs
> >
> >
> >
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
Posted by John D Groenveld <jd...@elvis.arl.psu.edu>.
In message <A9...@Pharmacy.Arizona.EDU>, Bruce J
ohnson writes:
>when I run it with /bin/env -i I get:
>
>/bin/env -i /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>linux-vdso.so.1 =3D> (0x00007fff2d9ff000)
>libocci.so.11.1 =3D> not found
>libclntsh.so.11.1 =3D> not found
>libpthread.so.0 =3D> /lib64/libpthread.so.0 (0x00007f55049da000)
>libc.so.6 =3D> /lib64/libc.so.6 (0x00007f5504647000)
>/lib64/ld-linux-x86-64.so.2 (0x00007f5504e43000)
>
>However I don't understand what this means...
It means that you should rebuild DBD::Oracle but add the -rpath
option to the LDFLAGS in the generated Makefile to properly hint
the runtime linker where to find the Oracle Instant Client libraries.
Then you should find every instance of LD_LIBRARY_PATH= in
the shell init files in /etc as well as the ones in your
Apache configuration and remove them.
My WAG is that the Oracle packages for Unbreakable Linux
*un*helpfully added LD_LIBRARY_PATH=/path/to/instantclient_11_2
to your /etc/profile and friends.
John
groenveld@acm.org
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
Posted by John D Groenveld <jd...@elvis.arl.psu.edu>.
In message <38...@Pharmacy.Arizona.EDU>, Bruce J
ohnson writes:
># su -s /bin/sh apache
Try again...
<URL:http://man7.org/linux/man-pages/man1/su.1.html>
<URL:http://man7.org/linux/man-pages/man1/env.1.html>
# su -s /bin/sh - apache
$ /bin/env
John
groenveld@acm
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by "Thomas M. Payerle" <pa...@umd.edu>.
On Mon, 21 Oct 2013, Bruce Johnson wrote:
>
> On Oct 21, 2013, at 2:56 PM, Thomas M. Payerle <pa...@umd.edu> wrote:
>
>> On Mon, 21 Oct 2013, Bruce Johnson wrote:
>>
>> Is your mod_perl setuid/setgid? If so LD_LIBRARY_PATH gets ignored.
>>
>
> I don't think so, but even so, shouldn't the PerlSetEnv directive be followed? Isn't that the point of a PerlSetEnv directive?
>
The PerlSetEnv directive will set LD_LIBRARY_PATH, but the question is whether
it is used in the dynamic loading phase. In the simplest case of a setuid
binary foo, when I run foo, ld.so will ignore LD_LIBRARY_PATH and only search
for libs in the system standard places. To do otherwise allows me to escalate
my privs.
I don't think things are exactly the same when a program like apache dynamically
loads the mod_perl code, which then dynamically loads (or tries to load)
Oracle.so and the oracle client libraries, but presumably, for the same
security reasons, it should ignore LD_LIBRARY_PATH.
And I guess my question should have been is apache setuid/setgid (although
I would check mod_perl as well, but that probably is not relevant).
>> My guess would be that the dependent libraries of Oracle.so are not being
>> picked up for some reason, despite ldd "finding" them. One thing you might try
>> is to set LD_PRELOAD to the paths to libocci and libclntsh (from man page
>> looks like should be whitespace separated), before starting apache, and see
>> if that gets things to work. Probably not a good long term solution (as
>> likely adds bloat to httpd processes), but will at least confirm that the
>> problem is that it is not finding those libs during the dynamic load.
>
> It's not strictly an Apache problem, because the script works on this server when it's set to run as a CGI program.
>
> Also I'm not clear what LD_PRELOAD would accomplish that LD_LIBRARY_PATH does not. These are not subsitute libraries, they're the only libocci libraries on the system. I've had issues like this when i have both oracle and the instant client running on the same system, but properly setting LD_LIBRARY_PATH and ORACLE_HOME deal with that in Apache.
>
The info in your email exchange with John D Groenveld seems to make this moot.
My suggestion of LD_PRELOAD was for the following reasons:
1) CGI scripts get started as new processes, and ld.so will get called and load the perl and all. I believe there are subtle differences between that process
and how everything is loaded when done through dlopen. LD_PRELOAD will load
specified libraries immediately, so if something subtle is breaking so that
dlopen is not finding the proper libraries that Oracle.so depends on, it should
still work if you preload the needed libraries.
2) As John Groenveld showed, it looks like LD_LIBRARY_PATH is getting changed
at some point in the process. LD_PRELOAD occurs early in the process, before
Apache is even loaded, which means there is much less time for anything to
confuse the issue.
I concur that it seemed like what you were doing with LD_LIBRARY_PATH _should_
work, but as it is was not working, and problems with loading of libraries seems
a likely candidate for the cause, I was suggesting trying LD_PRELOAD because
it is a simpler, more easily understood process (at least to me the locating of
shared libraries can sometimes be complicated), and it occurs at an earlier
stage in the process before things get more convoluted. I have in the past
found it an useful tool for debugging problems, at least to the point of
confirming that it _is_ a problem loading the dependent libraries, and which
ones.
>
>
>>
>>>
>>> On Oct 21, 2013, at 2:03 PM, John D Groenveld <jd...@elvis.arl.psu.edu>
>>> wrote:
>>>
>>>> In message <48...@pharmacy.arizona.edu>, Bruce J
>>>> ohnson writes:
>>>>> Nope, that looks right:
>>>>>
>>>>> # ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>>>> linux-vdso.so.1 => (0x00007fffc8980000)
>>>>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>>>>> x00007fb39a816000)
>>>>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>>>>> 1 (0x00007fb397f84000)
>>>>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
>>>>> libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
>>>>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
>>>>> libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
>>>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
>>>>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>>>>> 396e5c000)
>>>>> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
>>>>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
>>>>> libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
>>>>> /lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>>>>>
>>>>>
>>>>> Also, if the linking was wrong here, it wouldn't work on the command line or a
>>>>> s a CGI script, either, I'd think.
>>>>
>>>> As the webserver user?
>>>> # su - apache
>>>> $ /bin/printenv
>>>> $ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>>>
>>>
>>> # su -s /bin/sh apache
>>> sh-4.1$ /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>> linux-vdso.so.1 => (0x00007fff047a7000)
>>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007f659f56c000)
>>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007f659ccda000)
>>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f659cab3000)
>>> libc.so.6 => /lib64/libc.so.6 (0x00007f659c720000)
>>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f659c419000)
>>> libm.so.6 => /lib64/libm.so.6 (0x00007f659c195000)
>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f659bf7f000)
>>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007f659bbb2000)
>>> libdl.so.2 => /lib64/libdl.so.2 (0x00007f659b9ae000)
>>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f659b795000)
>>> libaio.so.1 => /lib64/libaio.so.1 (0x00007f659b593000)
>>> /lib64/ld-linux-x86-64.so.2 (0x00007f659fa04000)
>>>
>>>
>>> Nope.
>>>
>>> And if it were an issue under apache, the script would break when run as a CGI program, which it doesn't.
>>>
>>> It only breaks under mod_perl.
>>>
>>>
>>> --
>>> Bruce Johnson
>>> University of Arizona
>>> College of Pharmacy
>>> Information Technology Group
>>>
>>> Institutions do not have opinions, merely customs
>>>
>>>
>>>
>>
>> Tom Payerle
>> IT-ETI-EUS payerle@umd.edu
>> University of Maryland (301) 405-6135
>> College Park, MD 20742-4111
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>
Tom Payerle
IT-ETI-EUS payerle@umd.edu
University of Maryland (301) 405-6135
College Park, MD 20742-4111
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Bruce Johnson <jo...@Pharmacy.Arizona.EDU>.
On Oct 21, 2013, at 2:56 PM, Thomas M. Payerle <pa...@umd.edu> wrote:
> On Mon, 21 Oct 2013, Bruce Johnson wrote:
>
> Based on path, sounds like you have a 64 bit version of Oracle. I am
> assuming that you verified that your mod_perl is a 64 bit build.
>
yes it is.
> Is your mod_perl setuid/setgid? If so LD_LIBRARY_PATH gets ignored.
>
I don't think so, but even so, shouldn't the PerlSetEnv directive be followed? Isn't that the point of a PerlSetEnv directive?
> My guess would be that the dependent libraries of Oracle.so are not being
> picked up for some reason, despite ldd "finding" them. One thing you might try
> is to set LD_PRELOAD to the paths to libocci and libclntsh (from man page
> looks like should be whitespace separated), before starting apache, and see
> if that gets things to work. Probably not a good long term solution (as
> likely adds bloat to httpd processes), but will at least confirm that the
> problem is that it is not finding those libs during the dynamic load.
It's not strictly an Apache problem, because the script works on this server when it's set to run as a CGI program.
Also I'm not clear what LD_PRELOAD would accomplish that LD_LIBRARY_PATH does not. These are not subsitute libraries, they're the only libocci libraries on the system. I've had issues like this when i have both oracle and the instant client running on the same system, but properly setting LD_LIBRARY_PATH and ORACLE_HOME deal with that in Apache.
>
>>
>> On Oct 21, 2013, at 2:03 PM, John D Groenveld <jd...@elvis.arl.psu.edu>
>> wrote:
>>
>>> In message <48...@pharmacy.arizona.edu>, Bruce J
>>> ohnson writes:
>>>> Nope, that looks right:
>>>>
>>>> # ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>>> linux-vdso.so.1 => (0x00007fffc8980000)
>>>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>>>> x00007fb39a816000)
>>>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>>>> 1 (0x00007fb397f84000)
>>>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
>>>> libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
>>>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
>>>> libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
>>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
>>>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>>>> 396e5c000)
>>>> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
>>>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
>>>> libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
>>>> /lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>>>>
>>>>
>>>> Also, if the linking was wrong here, it wouldn't work on the command line or a
>>>> s a CGI script, either, I'd think.
>>>
>>> As the webserver user?
>>> # su - apache
>>> $ /bin/printenv
>>> $ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>>
>>
>> # su -s /bin/sh apache
>> sh-4.1$ /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>> linux-vdso.so.1 => (0x00007fff047a7000)
>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007f659f56c000)
>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007f659ccda000)
>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f659cab3000)
>> libc.so.6 => /lib64/libc.so.6 (0x00007f659c720000)
>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f659c419000)
>> libm.so.6 => /lib64/libm.so.6 (0x00007f659c195000)
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f659bf7f000)
>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007f659bbb2000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x00007f659b9ae000)
>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f659b795000)
>> libaio.so.1 => /lib64/libaio.so.1 (0x00007f659b593000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007f659fa04000)
>>
>>
>> Nope.
>>
>> And if it were an issue under apache, the script would break when run as a CGI program, which it doesn't.
>>
>> It only breaks under mod_perl.
>>
>>
>> --
>> Bruce Johnson
>> University of Arizona
>> College of Pharmacy
>> Information Technology Group
>>
>> Institutions do not have opinions, merely customs
>>
>>
>>
>
> Tom Payerle
> IT-ETI-EUS payerle@umd.edu
> University of Maryland (301) 405-6135
> College Park, MD 20742-4111
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by "Thomas M. Payerle" <pa...@umd.edu>.
On Mon, 21 Oct 2013, Bruce Johnson wrote:
Based on path, sounds like you have a 64 bit version of Oracle. I am
assuming that you verified that your mod_perl is a 64 bit build.
Is your mod_perl setuid/setgid? If so LD_LIBRARY_PATH gets ignored.
My guess would be that the dependent libraries of Oracle.so are not being
picked up for some reason, despite ldd "finding" them. One thing you might try
is to set LD_PRELOAD to the paths to libocci and libclntsh (from man page
looks like should be whitespace separated), before starting apache, and see
if that gets things to work. Probably not a good long term solution (as
likely adds bloat to httpd processes), but will at least confirm that the
problem is that it is not finding those libs during the dynamic load.
>
> On Oct 21, 2013, at 2:03 PM, John D Groenveld <jd...@elvis.arl.psu.edu>
> wrote:
>
>> In message <48...@pharmacy.arizona.edu>, Bruce J
>> ohnson writes:
>>> Nope, that looks right:
>>>
>>> # ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>> linux-vdso.so.1 => (0x00007fffc8980000)
>>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>>> x00007fb39a816000)
>>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>>> 1 (0x00007fb397f84000)
>>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
>>> libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
>>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
>>> libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
>>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
>>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>>> 396e5c000)
>>> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
>>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
>>> libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
>>> /lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>>>
>>>
>>> Also, if the linking was wrong here, it wouldn't work on the command line or a
>>> s a CGI script, either, I'd think.
>>
>> As the webserver user?
>> # su - apache
>> $ /bin/printenv
>> $ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>
>
> # su -s /bin/sh apache
> sh-4.1$ /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
> linux-vdso.so.1 => (0x00007fff047a7000)
> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007f659f56c000)
> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007f659ccda000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f659cab3000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f659c720000)
> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f659c419000)
> libm.so.6 => /lib64/libm.so.6 (0x00007f659c195000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f659bf7f000)
> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007f659bbb2000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f659b9ae000)
> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f659b795000)
> libaio.so.1 => /lib64/libaio.so.1 (0x00007f659b593000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f659fa04000)
>
>
> Nope.
>
> And if it were an issue under apache, the script would break when run as a CGI program, which it doesn't.
>
> It only breaks under mod_perl.
>
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>
Tom Payerle
IT-ETI-EUS payerle@umd.edu
University of Maryland (301) 405-6135
College Park, MD 20742-4111
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Bruce Johnson <jo...@Pharmacy.Arizona.EDU>.
On Oct 21, 2013, at 2:03 PM, John D Groenveld <jd...@elvis.arl.psu.edu>
wrote:
> In message <48...@pharmacy.arizona.edu>, Bruce J
> ohnson writes:
>> Nope, that looks right:
>>
>> # ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>> linux-vdso.so.1 => (0x00007fffc8980000)
>> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>> x00007fb39a816000)
>> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>> 1 (0x00007fb397f84000)
>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
>> libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
>> libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
>> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>> 396e5c000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
>> libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>>
>>
>> Also, if the linking was wrong here, it wouldn't work on the command line or a
>> s a CGI script, either, I'd think.
>
> As the webserver user?
> # su - apache
> $ /bin/printenv
> $ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>
# su -s /bin/sh apache
sh-4.1$ /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
linux-vdso.so.1 => (0x00007fff047a7000)
libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007f659f56c000)
libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007f659ccda000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f659cab3000)
libc.so.6 => /lib64/libc.so.6 (0x00007f659c720000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f659c419000)
libm.so.6 => /lib64/libm.so.6 (0x00007f659c195000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f659bf7f000)
libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007f659bbb2000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f659b9ae000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f659b795000)
libaio.so.1 => /lib64/libaio.so.1 (0x00007f659b593000)
/lib64/ld-linux-x86-64.so.2 (0x00007f659fa04000)
Nope.
And if it were an issue under apache, the script would break when run as a CGI program, which it doesn't.
It only breaks under mod_perl.
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
Posted by John D Groenveld <jd...@elvis.arl.psu.edu>.
In message <48...@pharmacy.arizona.edu>, Bruce J
ohnson writes:
>Nope, that looks right:
>
># ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
> linux-vdso.so.1 => (0x00007fffc8980000)
> libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>x00007fb39a816000)
> libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>1 (0x00007fb397f84000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
> libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
> libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
> libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>396e5c000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
> libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>
>
>Also, if the linking was wrong here, it wouldn't work on the command line or a
>s a CGI script, either, I'd think.
As the webserver user?
# su - apache
$ /bin/printenv
$ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
John
groenveld@acm.org
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Bruce Johnson <jo...@Pharmacy.Arizona.EDU>.
On Oct 21, 2013, at 12:57 PM, John D Groenveld <jd...@elvis.arl.psu.edu> wrote:
> In message <76...@pharmacy.arizona.edu>, Bruce J
> ohnson writes:
>> DBD::Oracle was properly compiled, else it wouldn't work on the command line,
>> either.
>
> Out of my depth with Linux, but perhaps this will help:
> $ env - /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
Nope, that looks right:
# ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
linux-vdso.so.1 => (0x00007fffc8980000)
libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007fb39a816000)
libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007fb397f84000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb396e5c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
Also, if the linking was wrong here, it wouldn't work on the command line or as a CGI script, either, I'd think.
This is maddening.
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?
Posted by John D Groenveld <jd...@elvis.arl.psu.edu>.
In message <76...@pharmacy.arizona.edu>, Bruce J
ohnson writes:
>DBD::Oracle was properly compiled, else it wouldn't work on the command line,
>either.
Out of my depth with Linux, but perhaps this will help:
$ env - /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
Assuming ldd can't find libclntsh.so, try reinstalling DBD::Oracle
with -rpath specified and removing LD_LIBRARY_PATH from your
environment.
<URL:http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html>
John
groenveld@acm.org
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Michael Lackhoff <mi...@lackhoff.de>.
Am 21.10.2013 22:23, schrieb Dr James A Smith:
> You may have some "quirk" going on with DBD::Oracle - it has a nasty
> BEGIN block in it which
> does some nasty stuff... I had a three day head scratch with this module
> moving from Lucid to
> Precise as it was not finding the tnsnames files - in the end I had to
> set up the environment
> before starting up apache. As the Env settings int the config were not
> in place when DBD::Oracle
> was used for the first time. Not sure when it is being used tho' but it
> took a lot of "root"y
> hacking to discover the problem!
That rings a bell. I remember having problems when I 'use'ed DBD::Oracle
in startup.pl but it worked fine as soon as I didn't try to preload it.
At least worth a try...
-Michael
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Dr James A Smith <js...@sanger.ac.uk>.
You may have some "quirk" going on with DBD::Oracle - it has a nasty
BEGIN block in it which
does some nasty stuff... I had a three day head scratch with this module
moving from Lucid to
Precise as it was not finding the tnsnames files - in the end I had to
set up the environment
before starting up apache. As the Env settings int the config were not
in place when DBD::Oracle
was used for the first time. Not sure when it is being used tho' but it
took a lot of "root"y
hacking to discover the problem!
James
On 21/10/2013 19:37, Bruce Johnson wrote:
> On Oct 21, 2013, at 11:20 AM, Fred Moyer <fr...@redhotpenguin.com> wrote:
>
>> This is annoying but it happens on 64 bit architectures.
>>
>>> The path is correct, the script works fine on the command line, and if I comment out the handler directives in the perl.conf script, put in a ScriptAlias and process the script as a normal CGI script, it also works.
>> Sounds like some environment variable is not getting passed correctly to mod_perl. Maybe dump out %ENV from the command line and see if there are additional vars you need to pass?
> Nope, good idea but the vars I need are present, even with the modperl handler in place. The only ones you need for DBD::Oracle to work are ORACLE_HOME and LD_LIBRARY_PATH
>
> DBD::Oracle was properly compiled, else it wouldn't work on the command line, either.
>
>> I'd dump out %INC from the command line and mod_perl also to make sure that you are loading the needed modules. You could try to install DBD::Oracle in /usr/lib instead of /usr/local/lib also - my guess is that it's looking for the Oracle.so in /usr/local/lib but it is located somewhere else.
> With mod_perl there is just one more, /etc/httpd
>
> command line:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
>
> server:
>
> INC-> /usr/local/lib64/perl5
> INC-> /usr/local/share/perl5
> INC-> /usr/lib64/perl5/vendor_perl
> INC-> /usr/share/perl5/vendor_perl
> INC-> /usr/lib64/perl5
> INC-> /usr/share/perl5
> INC-> .
> INC-> /etc/httpd
>
>
>>
>> On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <jo...@pharmacy.arizona.edu> wrote:
>> We've set a Directory directive for some perl scripts, setting a mod_perl handler:
>>
>> Alias /card_access /home/allwebfiles/perl/catcard
>>
>> <Directory /home/allwebfiles/perl/catcard>
>> SetHandler perl-script
>> PerlResponseHandler ModPerl::Registry
>> PerlOptions +ParseHeaders
>> Options +ExecCGI
>> PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
>> PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
>> </Directory>
>>
>> The %ENV variable is there, if I print the %ENV values:
>>
>> LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
>> MOD_PERL --> mod_perl/2.0.4
>> MOD_PERL_API_VERSION --> 2
>> ORACLE_HOME --> /usr/lib/oracle/11.2/client64
>> PATH --> /sbin:/usr/sbin:/bin:/usr/bin
>>
>> But trying to initialize a DBI database connection results in the following error:
>>
>> [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11) line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a required shared library or dll isn't installed where expected\n at /home/allwebfiles/perl/catcard/oratest.pl line 9\n
>>
>> Which is precisely the error you get when LD_LIBRARY_PATH is unset or incorrect.
>>
>> libocci.so.11.1 is where it's supposed to be.
>>
>> [root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
>> total 185016
>> -rw-r--r-- 1 root root 368 Sep 17 2011 glogin.sql
>> lrwxrwxrwx 1 root root 17 May 20 12:07 libclntsh.so -> libclntsh.so.11.1
>> -rw-r--r-- 1 root root 52761218 Sep 17 2011 libclntsh.so.11.1
>> -rw-r--r-- 1 root root 7955322 Sep 17 2011 libnnz11.so
>> lrwxrwxrwx 1 root root 15 May 20 12:07 libocci.so -> libocci.so.11.1
>> -rw-r--r-- 1 root root 1971762 Sep 17 2011 libocci.so.11.1
>> -rw-r--r-- 1 root root 118408281 Sep 17 2011 libociei.so
>> -rw-r--r-- 1 root root 164836 Sep 17 2011 libocijdbc11.so
>> -rw-r--r-- 1 root root 1503303 Sep 17 2011 libsqlplusic.so
>> -rw-r--r-- 1 root root 1477446 Sep 17 2011 libsqlplus.so
>> -rw-r--r-- 1 root root 2095661 Sep 17 2011 ojdbc5.jar
>> -rw-r--r-- 1 root root 2714016 Sep 17 2011 ojdbc6.jar
>> -rw-r--r-- 1 root root 300666 Sep 17 2011 ottclasses.zip
>> -rw-r--r-- 1 root root 66779 Sep 17 2011 xstreams.jar
>>
>> The path is correct, the script works fine on the command line, and if I comment out the handler directives in the perl.conf script, put in a ScriptAlias and process the script as a normal CGI script, it also works.
>>
>> I'm confident the issue doesn't have anything to do with DBI or DBD::Oracle.
>>
>> It ONLY fails when the script is executed as a mod_perl handler.
>>
>> The script itself is very simple; all I do is create a database handle and if no error is thrown, print 'It works'.
>>
>> #!/usr/bin/perl
>> use DBI;
>> use strict;
>>
>> my $login="xxxxxx";
>> my $dbpass='xxxxxxxx';
>> my $dbname="host=xxx.xxx.xxx.xx;sid=xxx";
>> my $dbh = DBI->connect("dbi:Oracle:$dbname", $login, $dbpass, {RaiseError =>1});
>>
>> print "Content-type: text/html\n\n";
>> print "It Works";
>> exit;
>>
>> (and this is just a test , any script using DBI fails with this error.)
>>
>> What am I missing?
>>
>> --
>> Bruce Johnson
>> University of Arizona
>> College of Pharmacy
>> Information Technology Group
>>
>> Institutions do not have opinions, merely customs
>>
>>
>>
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Bruce Johnson <jo...@Pharmacy.Arizona.EDU>.
On Oct 21, 2013, at 11:20 AM, Fred Moyer <fr...@redhotpenguin.com> wrote:
> This is annoying but it happens on 64 bit architectures.
>
> > The path is correct, the script works fine on the command line, and if I comment out the handler directives in the perl.conf script, put in a ScriptAlias and process the script as a normal CGI script, it also works.
>
> Sounds like some environment variable is not getting passed correctly to mod_perl. Maybe dump out %ENV from the command line and see if there are additional vars you need to pass?
Nope, good idea but the vars I need are present, even with the modperl handler in place. The only ones you need for DBD::Oracle to work are ORACLE_HOME and LD_LIBRARY_PATH
DBD::Oracle was properly compiled, else it wouldn't work on the command line, either.
>
> I'd dump out %INC from the command line and mod_perl also to make sure that you are loading the needed modules. You could try to install DBD::Oracle in /usr/lib instead of /usr/local/lib also - my guess is that it's looking for the Oracle.so in /usr/local/lib but it is located somewhere else.
With mod_perl there is just one more, /etc/httpd
command line:
INC-> /usr/local/lib64/perl5
INC-> /usr/local/share/perl5
INC-> /usr/lib64/perl5/vendor_perl
INC-> /usr/share/perl5/vendor_perl
INC-> /usr/lib64/perl5
INC-> /usr/share/perl5
INC-> .
server:
INC-> /usr/local/lib64/perl5
INC-> /usr/local/share/perl5
INC-> /usr/lib64/perl5/vendor_perl
INC-> /usr/share/perl5/vendor_perl
INC-> /usr/lib64/perl5
INC-> /usr/share/perl5
INC-> .
INC-> /etc/httpd
>
>
> On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <jo...@pharmacy.arizona.edu> wrote:
> We've set a Directory directive for some perl scripts, setting a mod_perl handler:
>
> Alias /card_access /home/allwebfiles/perl/catcard
>
> <Directory /home/allwebfiles/perl/catcard>
> SetHandler perl-script
> PerlResponseHandler ModPerl::Registry
> PerlOptions +ParseHeaders
> Options +ExecCGI
> PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
> PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
> </Directory>
>
> The %ENV variable is there, if I print the %ENV values:
>
> LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
> MOD_PERL --> mod_perl/2.0.4
> MOD_PERL_API_VERSION --> 2
> ORACLE_HOME --> /usr/lib/oracle/11.2/client64
> PATH --> /sbin:/usr/sbin:/bin:/usr/bin
>
> But trying to initialize a DBI database connection results in the following error:
>
> [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11) line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a required shared library or dll isn't installed where expected\n at /home/allwebfiles/perl/catcard/oratest.pl line 9\n
>
> Which is precisely the error you get when LD_LIBRARY_PATH is unset or incorrect.
>
> libocci.so.11.1 is where it's supposed to be.
>
> [root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
> total 185016
> -rw-r--r-- 1 root root 368 Sep 17 2011 glogin.sql
> lrwxrwxrwx 1 root root 17 May 20 12:07 libclntsh.so -> libclntsh.so.11.1
> -rw-r--r-- 1 root root 52761218 Sep 17 2011 libclntsh.so.11.1
> -rw-r--r-- 1 root root 7955322 Sep 17 2011 libnnz11.so
> lrwxrwxrwx 1 root root 15 May 20 12:07 libocci.so -> libocci.so.11.1
> -rw-r--r-- 1 root root 1971762 Sep 17 2011 libocci.so.11.1
> -rw-r--r-- 1 root root 118408281 Sep 17 2011 libociei.so
> -rw-r--r-- 1 root root 164836 Sep 17 2011 libocijdbc11.so
> -rw-r--r-- 1 root root 1503303 Sep 17 2011 libsqlplusic.so
> -rw-r--r-- 1 root root 1477446 Sep 17 2011 libsqlplus.so
> -rw-r--r-- 1 root root 2095661 Sep 17 2011 ojdbc5.jar
> -rw-r--r-- 1 root root 2714016 Sep 17 2011 ojdbc6.jar
> -rw-r--r-- 1 root root 300666 Sep 17 2011 ottclasses.zip
> -rw-r--r-- 1 root root 66779 Sep 17 2011 xstreams.jar
>
> The path is correct, the script works fine on the command line, and if I comment out the handler directives in the perl.conf script, put in a ScriptAlias and process the script as a normal CGI script, it also works.
>
> I'm confident the issue doesn't have anything to do with DBI or DBD::Oracle.
>
> It ONLY fails when the script is executed as a mod_perl handler.
>
> The script itself is very simple; all I do is create a database handle and if no error is thrown, print 'It works'.
>
> #!/usr/bin/perl
> use DBI;
> use strict;
>
> my $login="xxxxxx";
> my $dbpass='xxxxxxxx';
> my $dbname="host=xxx.xxx.xxx.xx;sid=xxx";
> my $dbh = DBI->connect("dbi:Oracle:$dbname", $login, $dbpass, {RaiseError =>1});
>
> print "Content-type: text/html\n\n";
> print "It Works";
> exit;
>
> (and this is just a test , any script using DBI fails with this error.)
>
> What am I missing?
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not
being recognized?
Posted by Fred Moyer <fr...@redhotpenguin.com>.
This is annoying but it happens on 64 bit architectures.
> The path is correct, the script works fine on the command line, and if I
comment out the handler directives in the perl.conf script, put in a
ScriptAlias and process the script as a normal CGI script, it also works.
Sounds like some environment variable is not getting passed correctly to
mod_perl. Maybe dump out %ENV from the command line and see if there are
additional vars you need to pass?
I'd dump out %INC from the command line and mod_perl also to make sure that
you are loading the needed modules. You could try to install DBD::Oracle in
/usr/lib instead of /usr/local/lib also - my guess is that it's looking for
the Oracle.so in /usr/local/lib but it is located somewhere else.
On Mon, Oct 21, 2013 at 10:57 AM, Bruce Johnson <
johnson@pharmacy.arizona.edu> wrote:
> We've set a Directory directive for some perl scripts, setting a mod_perl
> handler:
>
> Alias /card_access /home/allwebfiles/perl/catcard
>
> <Directory /home/allwebfiles/perl/catcard>
> SetHandler perl-script
> PerlResponseHandler ModPerl::Registry
> PerlOptions +ParseHeaders
> Options +ExecCGI
> PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
> PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
> </Directory>
>
> The %ENV variable is there, if I print the %ENV values:
>
> LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
> MOD_PERL --> mod_perl/2.0.4
> MOD_PERL_API_VERSION --> 2
> ORACLE_HOME --> /usr/lib/oracle/11.2/client64
> PATH --> /sbin:/usr/sbin:/bin:/usr/bin
>
> But trying to initialize a DBI database connection results in the
> following error:
>
> [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't
> load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module
> DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file
> or directory at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11)
> line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a
> required shared library or dll isn't installed where expected\n at
> /home/allwebfiles/perl/catcard/oratest.pl line 9\n
>
> Which is precisely the error you get when LD_LIBRARY_PATH is unset or
> incorrect.
>
> libocci.so.11.1 is where it's supposed to be.
>
> [root@merthiolate catcard]# ls -l /usr/lib/oracle/11.2/client64/lib
> total 185016
> -rw-r--r-- 1 root root 368 Sep 17 2011 glogin.sql
> lrwxrwxrwx 1 root root 17 May 20 12:07 libclntsh.so ->
> libclntsh.so.11.1
> -rw-r--r-- 1 root root 52761218 Sep 17 2011 libclntsh.so.11.1
> -rw-r--r-- 1 root root 7955322 Sep 17 2011 libnnz11.so
> lrwxrwxrwx 1 root root 15 May 20 12:07 libocci.so -> libocci.so.11.1
> -rw-r--r-- 1 root root 1971762 Sep 17 2011 libocci.so.11.1
> -rw-r--r-- 1 root root 118408281 Sep 17 2011 libociei.so
> -rw-r--r-- 1 root root 164836 Sep 17 2011 libocijdbc11.so
> -rw-r--r-- 1 root root 1503303 Sep 17 2011 libsqlplusic.so
> -rw-r--r-- 1 root root 1477446 Sep 17 2011 libsqlplus.so
> -rw-r--r-- 1 root root 2095661 Sep 17 2011 ojdbc5.jar
> -rw-r--r-- 1 root root 2714016 Sep 17 2011 ojdbc6.jar
> -rw-r--r-- 1 root root 300666 Sep 17 2011 ottclasses.zip
> -rw-r--r-- 1 root root 66779 Sep 17 2011 xstreams.jar
>
> The path is correct, the script works fine on the command line, and if I
> comment out the handler directives in the perl.conf script, put in a
> ScriptAlias and process the script as a normal CGI script, it also works.
>
> I'm confident the issue doesn't have anything to do with DBI or
> DBD::Oracle.
>
> It ONLY fails when the script is executed as a mod_perl handler.
>
> The script itself is very simple; all I do is create a database handle and
> if no error is thrown, print 'It works'.
>
> #!/usr/bin/perl
> use DBI;
> use strict;
>
> my $login="xxxxxx";
> my $dbpass='xxxxxxxx';
> my $dbname="host=xxx.xxx.xxx.xx;sid=xxx";
> my $dbh = DBI->connect("dbi:Oracle:$dbname", $login, $dbpass, {RaiseError
> =>1});
>
> print "Content-type: text/html\n\n";
> print "It Works";
> exit;
>
> (and this is just a test , any script using DBI fails with this error.)
>
> What am I missing?
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Bruce Johnson <jo...@Pharmacy.Arizona.EDU>.
On Oct 22, 2013, at 8:23 AM, Torsten Förtsch <to...@gmx.net> wrote:
>
> To me the problem seems to be %ENV being tied to $r->subprocess_env. So,
> neither PerlSetEnv nor SetEnv actually change the current process'
> environment. The reason for that the environment is a global resource in
> a potentially multi-threaded process.
I'm pretty sure that this is what's discussed in the docs here:
<http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#C_Libraries_Don_t_See_C__ENV__Entries_Set_by_Perl_Code>
When I do this in my startup.pl (which is included immediately after loading the mod_perl.so module)
I get the same error.
The entirety of my startup.pl is :
#!/usr/bin/perl
use strict;
$ENV{MOD_PERL} or die "not running under mod_perl!";
$ENV{'LD_LIBRARY_PATH'} = "/usr/lib/oracle/11.2/client64/lib";
$ENV{'ORACLE_HOME'} = "/usr/lib/oracle/11.2/client64";
$ENV{'WASIREAD'} ="Yes I was!";
1;
And it's in the environment:
DOCUMENT_ROOT --> /home/allwebfiles/static
GATEWAY_INTERFACE --> CGI/1.1
HTTPS --> on
HTTP_ACCEPT --> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
HTTP_ACCEPT_ENCODING --> gzip,deflate,sdch
HTTP_ACCEPT_LANGUAGE --> en-US,en;q=0.8
HTTP_CONNECTION --> keep-alive
HTTP_COOKIE --> __qca=P0-1946018635-1381167733063; SESS360e9fa4a6458358b044501f2b5b21b9=4862153113fc157562a1fc7691eecb36; __utma=219252696.1214622818.1382045504.1382045504.1382045504.1; __utmz=219252696.1382045504.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); CASAUTHOK=1
HTTP_HOST --> internal.pharmacy.arizona.edu
HTTP_USER_AGENT --> Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
MOD_PERL --> mod_perl/2.0.4
MOD_PERL_API_VERSION --> 2
ORACLE_HOME --> /usr/lib/oracle/11.2/client64
PATH --> /sbin:/usr/sbin:/bin:/usr/bin
QUERY_STRING -->
REMOTE_ADDR --> 128.196.45.237
REMOTE_PORT --> 58217
REQUEST_METHOD --> GET
REQUEST_URI --> /card_access/envvars.pl
SCRIPT_FILENAME --> /home/allwebfiles/perl/catcard/envvars.pl
SCRIPT_NAME --> /card_access/envvars.pl
SERVER_ADDR --> 150.135.124.49
SERVER_ADMIN --> root@localhost
SERVER_NAME --> internal.pharmacy.arizona.edu
SERVER_PORT --> 443
SERVER_PROTOCOL --> HTTP/1.1
SERVER_SIGNATURE -->
Apache/2.2.15 (Red Hat) Server at internal.pharmacy.arizona.edu Port 443
SERVER_SOFTWARE --> Apache/2.2.15 (Red Hat)
SSL_TLS_SNI --> internal.pharmacy.arizona.edu
WASIREAD --> Yes I was!
This is the perl script currently running in my head:
while ($damned_oracle.so_error){head->desk();}
Next stop, recompiling DBD::Oracle.
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Torsten Förtsch <to...@gmx.net>.
On 22/10/13 18:13, Bruce Johnson wrote:
>> To me the problem seems to be %ENV being tied to $r->subprocess_env. So,
>> > neither PerlSetEnv nor SetEnv actually change the current process'
>> > environment.
> Pardon me if this sounds dumb, but what possible use are those directives, then?
>
It's basically for CGI scripts. After the CGI script is forked but
before the exec, $r->subprocess_env is copied to the process environment.
Torsten
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Bruce Johnson <jo...@Pharmacy.Arizona.EDU>.
On Oct 22, 2013, at 8:23 AM, Torsten Förtsch <to...@gmx.net> wrote:
> On 21/10/13 19:57, Bruce Johnson wrote:
>> We've set a Directory directive for some perl scripts, setting a mod_perl handler:
>>
>> Alias /card_access /home/allwebfiles/perl/catcard
>>
>> <Directory /home/allwebfiles/perl/catcard>
>> SetHandler perl-script
>> PerlResponseHandler ModPerl::Registry
>> PerlOptions +ParseHeaders
>> Options +ExecCGI
>> PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
>> PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
>> </Directory>
>>
>> The %ENV variable is there, if I print the %ENV values:
>>
>> LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
>> MOD_PERL --> mod_perl/2.0.4
>> MOD_PERL_API_VERSION --> 2
>> ORACLE_HOME --> /usr/lib/oracle/11.2/client64
>> PATH --> /sbin:/usr/sbin:/bin:/usr/bin
>>
>> But trying to initialize a DBI database connection results in the following error:
>>
>> [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11) line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a required shared library or dll isn't installed where expected\n at /home/allwebfiles/perl/catcard/oratest.pl line 9\n
>>
> I haven't read the whole thread. So, I apologize if I state what
> somebody else has already explained.
>
> To me the problem seems to be %ENV being tied to $r->subprocess_env. So,
> neither PerlSetEnv nor SetEnv actually change the current process'
> environment.
Pardon me if this sounds dumb, but what possible use are those directives, then?
> The reason for that the environment is a global resource in
> a potentially multi-threaded process.
>
> If you don't need these variables set differently for different requests
> you can perhaps set them before starting httpd. Or you can set them
> perhaps in a <perl> section or similar.
>
That's one thing I don't think we've tried. What I still don't understand is how PerlSetEnv variables ARE present in the Apache process handled by that perl handler, but not in the perl handler code itself.
Even setting "%ENV{'LD_LIBRARY_PATH'}= <path to libs>;" in the perl handler code itself fails, and if the handler code cannot alter it's own process, then I'm stuck.
I'll try recompiling DBD::Oracle.
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is
not being recognized?
Posted by Torsten Förtsch <to...@gmx.net>.
On 21/10/13 19:57, Bruce Johnson wrote:
> We've set a Directory directive for some perl scripts, setting a mod_perl handler:
>
> Alias /card_access /home/allwebfiles/perl/catcard
>
> <Directory /home/allwebfiles/perl/catcard>
> SetHandler perl-script
> PerlResponseHandler ModPerl::Registry
> PerlOptions +ParseHeaders
> Options +ExecCGI
> PerlSetEnv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
> PerlSetEnv ORACLE_HOME /usr/lib/oracle/11.2/client64
> </Directory>
>
> The %ENV variable is there, if I print the %ENV values:
>
> LD_LIBRARY_PATH --> /usr/lib/oracle/11.2/client64/lib
> MOD_PERL --> mod_perl/2.0.4
> MOD_PERL_API_VERSION --> 2
> ORACLE_HOME --> /usr/lib/oracle/11.2/client64
> PATH --> /sbin:/usr/sbin:/bin:/usr/bin
>
> But trying to initialize a DBI database connection results in the following error:
>
> [Mon Oct 21 10:10:37 2013] [error] install_driver(Oracle) failed: Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libocci.so.11.1: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 200.\n at (eval 11) line 3\nCompilation failed in require at (eval 11) line 3.\nPerhaps a required shared library or dll isn't installed where expected\n at /home/allwebfiles/perl/catcard/oratest.pl line 9\n
>
I haven't read the whole thread. So, I apologize if I state what
somebody else has already explained.
To me the problem seems to be %ENV being tied to $r->subprocess_env. So,
neither PerlSetEnv nor SetEnv actually change the current process'
environment. The reason for that the environment is a global resource in
a potentially multi-threaded process.
If you don't need these variables set differently for different requests
you can perhaps set them before starting httpd. Or you can set them
perhaps in a <perl> section or similar.
If you need them differently make sure not to run a threaded MPM. Then
there is a module named Env::C or C::Env on CPAN that can help to modify
the real process environment.
Torsten