Re: How to suss out module dependencies...
One difference with what I did is that mine determines if the mod is a core mod and does not list it, if so. I was trying to parse through all of our homegrown packages and see what non-core mods (and versions) they depended on. didn't spend a lot of time making it prettier, so some calls were system calls to start perl within perl (seems yucky) and parsing STDOUT response, but it seemed to do the job, so it remained ugly... I agree with Dave about the fact that your setup should not need to be CPAN compliant in order for you to still get the dependeny list you want if you use CPAN::FindDependencies. bruce David McMath wrote: We dealt with a similar problem, moving from comfortable old server to a shiny new one. Perlmonks had some interesting advice: http://perlmonks.org/?node_id=203148 which I think is pretty cool (even though I only barely understand what it's going). One of our folks ended up, though, using the CPAN::FindDependencies module and writing some stuff that walks up through our use statements until it finds something that's not ours, then asks CPAN. You mention you're not using the normal CPAN model, but FindDependencies acutally goes back to a cpan site to get its answers, so maybe that's OK. Maybe this is helpful, dave William Bulley wrote: I have a question for which I have not been able to find a good answer. I have a Perl application that uses many Perl modules. Most come from CPAN, some I have written, others come with Perl distributions (core?). I am faced with the need to transport this collection of Perl code from operating system A to operating system B, both of which are perfectly well supported by Perl. Over several months I have added to system A lots of modules that need other modules. Unfortunately, system B is rather devoid of most of the modules that I need for this application. I dread having to make an inclusive list of all the modules and all the modules that those modules need, and so on, and so on. This is something that CPAN does when I install a new module that has dependencies on other modules. BUT in my case I am NOT using the blib, lib, t, MANIFEST, etc., etc., distribution model of CPAN, so I cannot use those tools - including several others on CPAN that compliment or implement this functionality. So my question is: is there a way to ask the Perl compiler/interpreter to spit out all the modules (and the other dependent modules) in my application in some format (a structured tree, a linear text file, etc.)? Failing that, are there some external tools that can accomplish this given my main module as a starting point? Thank you in advance. Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: dynamic lib ignored even after found in install_driver(Oracle) failed: Can't load... cgi problem
in (it appears.)
[the rest of this has to do with getting my web server to work correctly
with an ORACLE_SID environment variable i need passed into my CGI. if
you hard code this string in your CGI, you should be ready to go now.
i've just included this for my own notes and for anyone who might be
interested...]
okay, now i will try to run the script as an apache cgi script. here is
the resulting error (because i still need to do a little bit of
configuring of the web server so that it sees the ORACLE_SID environment
variable the script needs):
[Tue Sep 04 09:12:59 2007] [error] [client 127.0.0.1] Uncaught exception
from user code:
[Tue Sep 04 09:12:59 2007] [error] [client 127.0.0.1] \tDBI
connect('','scott',...) failed: ORA-12162: TNS:net service name is
incorrectly specified (DBD ERROR: OCIServerAttach) at
/var/www/cgi-bin/test2.pl line 19
[Tue Sep 04 09:12:59 2007] [error] [client 127.0.0.1] at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line 598
[Tue Sep 04 09:12:59 2007] [error] [client 127.0.0.1]
\tDBI::__ANON__('undef', 'undef') called at
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/DBI.pm line 648
[Tue Sep 04 09:12:59 2007] [error] [client 127.0.0.1]
\tDBI::connect('DBI', 'DBI:Oracle:', 'scott', 'tiger',
'HASH(0x9fecd40)') called at /var/www/cgi-bin/test2.pl line 19
the problem here is that the second argument of the connect call is
incomplete because $ENV{'ORACLE_SID'} in my script is not set. in order
to set this as an environment variable in the shell apache is started
in, i add the line
export ORACLE_SID=${ORACLE_SID:-xyz}
in the /etc/sysconfig/httpd file. [granted, setting such a global
environment variable for apache is a bit heavy-handed; we probably want
a control more local to the specific cgi running, but this is how i set
it up initially, so i'll figure out a nicer way later...]
if i run the script now, there's still a problem because apache does not
pass its environment into particular CGIs unless you tell it to do so in
the httpd.conf file. so after adding this line to my httpd.conf file:
PassEnv ORACLE_SID
finally, my script should work. here is the result of calling the
test2.pl cgi now:
ORACLE_SID = xyz
dbh = DBI::db=HASH(0x9f23ec4)
so we are finally getting a valid handle to our remote oracle database
in the CGI. yay!
hope this helps some people.
cheers,
bruce
Bruce Sears wrote:
ahhh... we are getting closer (?)
after running
strace -fFo trace_file /usr/sbin/httpd -X
it looks like it is some sort of permissions problem after all (?)
.
.
.
6177
open(/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/auto/DBD/Oracle/Oracle.so,
O_RDONLY) = 3
6177 read(3,
[EMAIL PROTECTED]..., 512) = 512
6177 fstat64(3, {st_mode=S_IFREG|0555, st_size=386943, ...}) = 0
6177 old_mmap(NULL, 194448, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x111000
6177 old_mmap(0x14, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2e000) = 0x14
6177 close(3) = 0
6177
open(/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libclntsh.so.10.1,
O_RDONLY) = -1 ENOENT (No such file or directory)
6177 open(/etc/ld.so.cache, O_RDONLY) = 3
6177 fstat64(3, {st_mode=S_IFREG|0644, st_size=82246, ...}) = 0
6177 old_mmap(NULL, 82246, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ecf000
6177 close(3) = 0
6177 open(/usr/local/instantclient_10_2/libclntsh.so.10.1,
O_RDONLY) = -1 EACCES (Permission denied)
6177 open(/lib/tls/i686/sse2/libclntsh.so.10.1, O_RDONLY) = -1
ENOENT (No such file or directory)
.
.
.
weird. it looks to me like apache SHOULD have read access to this
file, but it doesn't. am i missing some sort of configuration detail
regarding apache and permissions granted a cgi? i thought once the
server started a cgi, it basically had the run of the place (as much
access to the system as the apache user itself...)
okay, different tack. i edited the /etc/passwd file to set a login
shell for apache so i could su apache. i did this, and i am able to
read libclntsh.so.10.1 (i ran 'od libclntsh.so.10.1', and was not
denied permission. got lots of digits 8 :)
so, at least as a logged in user, apache does have read access to this
library. so why the Permission denied when trying to open it for my
test cgi?
big clue finally... i found that if i copied libclntsh.so.10.1 into a
trusted library location (/lib in this case, it does load. (and
just making a link to the library in /usr/local/instantclient_10_2/
does not work, not surprisingly.)) now the failure is at the loading
of another lib in /usr/local/instantclient_10_2/. i'm guessing this
must be part of the apache configuration, so i'll look more carefully
in the apache conf file now...
okay, i found nothing obvious there. but somewhere, something is
configuring these permissions restrictions into the httpd
executables. any ideas
Re: dynamic lib ignored even after found in install_driver(Oracle) failed: Can't load... cgi problem
thanks for the input tim (and charles), i have checked all the permissions, and these should be fine for access by the apache user. and when i ran as myself (not root), the command line execution did fine, too. -rwxrwxr-x 1 root root 18825267 Nov 15 2006 /usr/local/instantclient_10_2/libclntsh.so.10.1 drwxr-xr-x 4 root root 4096 Aug 30 16:56 /usr/local/instantclient_10_2/ drwxr-xr-x 20 root root 4096 Aug 30 17:26 /usr/local drwxr-xr-x 15 root root 4096 Jun 14 18:03 /usr drwxr-xr-x 23 root root 4096 Aug 27 14:38 / i will try the strace and see what i can see... thanks again, bruce Tim Kirby wrote: On 8/30/07 4:51 PM, Bruce Sears [EMAIL PROTECTED] wrote: thanks for bearing with this. it's too much detail, but perhaps not enough (sigh). Just glancing at this before retiring for the night; someone else will probably give you a real answer, but two things come to mind/might be worth looking at/whatever... (1) have you verified permissions for the library in question for whatever user the CGI is running as? I know the error didn't say permission denied, but you never know... (2) I would feel inclined to run the web server under strace, feeding the output to a file somewhere (make sure you're following children) and run your test case. There you will see the actual system calls that are being invoked and you should see a 'stat' and a real errno as to why it didn't open the library when it should have done. The trouble with debug aids of the kind you're using is it really depends on the people who wrote the debug code to have done the right thing everywhere. Color me cynical. So, there's my $0.02 FWIW. I may be in lala land, but that's what I would be looking at assuming I didn't misread what you posted. Good luck Tim
Re: dynamic lib ignored even after found in install_driver(Oracle) failed: Can't load... cgi problem
ahhh... we are getting closer (?)
after running
strace -fFo trace_file /usr/sbin/httpd -X
it looks like it is some sort of permissions problem after all (?)
.
.
.
6177
open(/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/auto/DBD/Oracle/Oracle.so,
O_RDONLY) = 3
6177 read(3,
[EMAIL PROTECTED]..., 512) = 512
6177 fstat64(3, {st_mode=S_IFREG|0555, st_size=386943, ...}) = 0
6177 old_mmap(NULL, 194448, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x111000
6177 old_mmap(0x14, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2e000) = 0x14
6177 close(3) = 0
6177
open(/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libclntsh.so.10.1,
O_RDONLY) = -1 ENOENT (No such file or directory)
6177 open(/etc/ld.so.cache, O_RDONLY) = 3
6177 fstat64(3, {st_mode=S_IFREG|0644, st_size=82246, ...}) = 0
6177 old_mmap(NULL, 82246, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ecf000
6177 close(3) = 0
6177 open(/usr/local/instantclient_10_2/libclntsh.so.10.1, O_RDONLY)
= -1 EACCES (Permission denied)
6177 open(/lib/tls/i686/sse2/libclntsh.so.10.1, O_RDONLY) = -1 ENOENT
(No such file or directory)
.
.
.
weird. it looks to me like apache SHOULD have read access to this file,
but it doesn't. am i missing some sort of configuration detail
regarding apache and permissions granted a cgi? i thought once the
server started a cgi, it basically had the run of the place (as much
access to the system as the apache user itself...)
okay, different tack. i edited the /etc/passwd file to set a login
shell for apache so i could su apache. i did this, and i am able to
read libclntsh.so.10.1 (i ran 'od libclntsh.so.10.1', and was not denied
permission. got lots of digits 8 :)
so, at least as a logged in user, apache does have read access to this
library. so why the Permission denied when trying to open it for my
test cgi?
big clue finally... i found that if i copied libclntsh.so.10.1 into a
trusted library location (/lib in this case, it does load. (and just
making a link to the library in /usr/local/instantclient_10_2/ does not
work, not surprisingly.)) now the failure is at the loading of another
lib in /usr/local/instantclient_10_2/. i'm guessing this must be part
of the apache configuration, so i'll look more carefully in the apache
conf file now...
okay, i found nothing obvious there. but somewhere, something is
configuring these permissions restrictions into the httpd executables.
any ideas anyone? do i really have to move all my libraries into /lib
(or /usr/lib probably works, too... ??)
thanks again for the help,
bruce
Bruce Sears wrote:
thanks for the input tim (and charles),
i have checked all the permissions, and these should be fine for
access by the apache user. and when i ran as myself (not root), the
command line execution did fine, too.
-rwxrwxr-x 1 root root 18825267 Nov 15 2006
/usr/local/instantclient_10_2/libclntsh.so.10.1
drwxr-xr-x 4 root root 4096 Aug 30 16:56 /usr/local/instantclient_10_2/
drwxr-xr-x 20 root root 4096 Aug 30 17:26 /usr/local
drwxr-xr-x 15 root root 4096 Jun 14 18:03 /usr
drwxr-xr-x 23 root root 4096 Aug 27 14:38 /
i will try the strace and see what i can see...
thanks again,
bruce
Tim Kirby wrote:
On 8/30/07 4:51 PM, Bruce Sears [EMAIL PROTECTED] wrote:
thanks for bearing with this. it's too much detail, but perhaps not
enough (sigh).
Just glancing at this before retiring for the night; someone else will
probably give you a real answer, but two things come to mind/might be
worth looking at/whatever...
(1) have you verified permissions for the library in question for whatever
user the CGI is running as? I know the error didn't say permission
denied, but you never know...
(2) I would feel inclined to run the web server under strace, feeding the
output to a file somewhere (make sure you're following children) and
run your test case. There you will see the actual system calls that
are being invoked and you should see a 'stat' and a real errno as to
why it didn't open the library when it should have done. The trouble
with debug aids of the kind you're using is it really depends on the
people who wrote the debug code to have done the right thing everywhere.
Color me cynical.
So, there's my $0.02 FWIW. I may be in lala land, but that's what I would
be looking at assuming I didn't misread what you posted.
Good luck
Tim
dynamic lib ignored even after found in install_driver(Oracle) failed: Can't load... cgi problem
hi all,
here's a problem it seems a lot of people are seeing when running a CGI
script
many people, including myself have had an ongoing problem with the
seemingly unfindable shared object library libclntsh.so.x.x (mine is
libclntsh.so.10.1) needed for connecting to a remote oracle database.
after installing the the sqlplus client (instantclient_10_2) on my linux
machine (and testing it on the command line, successfully connecting to
our oracle db), and then installing the perl module(s) needed to make
connections in perl scripts and cgis (DBD-Oracle-1.19), i find, like so
many others i've seen complain about this, that my cgi script runs fine
from the command line, but fails when it is run as a CGI via my
machine's apache webserver.
despite all the confident sermons about unset/mis-set environment
variables under apache (LD_LIBRARY_PATH, ORACLE_HOME, etc, etc) being
the problem (as one would first suspect, granted), changing these
settings does not fix this problem at all. i have played for hours with
these settings in BEGIN statements in the cgi, in the
/etc/sysconfig/httpd file, running httpd directly from the command line
with these env vars set in the current shell, and they DO show up when i
print out the @ENV array in the cgi, but to no avail in solving or
tracking down the problem. finally, i found one source which had more
ideas about how to analyze this problem:
http://www.mail-archive.com/dbi-users@perl.org/msg28109.html
by Philip Garrett. setting the env var
LD_DEBUG=libs
and then running httpd from the command line with the -X option allowed
me to see all the dynamic library searching and loading that was going
on behind the scenes. after adding the necessary PassEnv LD_DEBUG
directive to the apache config file, i can now see all the dynamic lib
loading, including that done for the CGI script via the web server.
what i am finding is that the library IS actually being found, but is
just being ignored as if it were not there.
i started by making sure libclntsh.so.10.1 could be found in the
/etc/ld.so.cache by adding the line
/usr/local/instantclient_10_2 to /etc/ld.so.conf and running ldconfig.
sure enough, it is now listed in the cache:
$ ldconfig -p | grep libclntsh
libclntsh.so.10.1 (libc6) =
/usr/local/instantclient_10_2/libclntsh.so.10.1
libclntsh.so (libc6) = /usr/local/instantclient_10_2/libclntsh.so
(/usr/local/libclntsh.so is a link to /usr/local/libclntsh.so.10.1 in
case this matters)
now, i run my script:
#!/usr/bin/perl -w
use Carp;
use diagnostics;
use DBI;
#BEGIN {
#$ENV{'LD_LIBRARY_PATH'} = /usr/local/instantclient_10_2;
#$ENV{'ORACLE_HOME'} = /usr/local/instantclient_10_2;
#}
print Content-type: text/html\n\n;
# print environment
foreach my $key (keys(%ENV)) {
if ($key =~ /^(LD|ORACLE)/) {
print $key = $ENV{$key}BR\n;
}
}
print BRBR\n;
my $ans = DBI-connect(DBI:Oracle:$ENV{'ORACLE_SID'},
'scott','tiger',
{ RaiseError = 1,
PrintError = 0,
AutoCommit = 0, } ) || print connection
failed\n ;
print ans = $ans\n\n;
$ans-disconnect;
from the command line (i unset LD_LIBRARY_PATH and ORACLE_HOME to show
they are not needed or used in any way here.)
% unsetenv LD_DEBUG
% unsetenv LD_LIBRARY_PATH
% unsetenv ORACLE_HOME
% perl test2.pl
Content-type: text/html
ORACLE_SID = epgyBR
BRBR
ans = DBI::db=HASH(0x867b0d0)
the last line shows that the connect to the oracle database worked
fine. ($ans is the handle to the oracle db.) running again, tracing the
lib loading:
% setenv LD_DEBUG libs
% perl test2.pl
14505: find library=libperl.so [0]; searching (and lots more
lines until...)
.
.
.
14505:
14505: initialize program: perl
14505:
14505:
14505: transferring control: perl
14505:
14505:
14505: calling init:
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/DBI.so
14505:
Content-type: text/html
LD_DEBUG = libsBR
ORACLE_SID = epgyBR
BRBR
14505: find library=libclntsh.so.10.1 [0]; searching
14505: search
path=/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE (RPATH from file
perl)
14505: trying
file=/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libclntsh.so.10.1
14505: search cache=/etc/ld.so.cache
14505: trying
file=/usr/local/instantclient_10_2/libclntsh.so.10.1 (((NOTE: Found
it!)))
14505:
14505: find library=libnnz10.so [0]; searching
.
.
.
14505: calling init:
/usr/local/instantclient_10_2/libclntsh.so.10.1
14505:
14505:
14505: calling init:
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/auto/DBD/Oracle/Oracle.so
.
.
.
ans = DBI::db=HASH(0x8b482dc)
.
.
.
again, we see that the connect has worked, after the libclntsh.so.10.1
was found and init'd successfully earlier in the process.
now i will run this script as a CGI
