-------- Original Message --------
Subject: Re: failed: ERROR OCIEnvNlsCreate. Check (everything)
Date: Thu, 8 Apr 2010 13:09:33 -0400
From: Perl Diety <misterp...@gmail.com>
To: Alexander Foken <alexan...@foken.de>
References:
<q2sb914e70a1004060656o63d399f3le68b76b458079...@mail.gmail.com>
<4bbc460f.5050...@easysoft.com> <4bbcf0b3.7010...@foken.de>
I wrote the script to dump %ENV (in a MUCH more Perlish way than the
apache version!) but yes, you're correct; I filtered out a lot of
unrelated stuff to make the list more friendly.
I don't think a linux apache server cares about *PATH* does it? Not
sure. The message seemed to imply PATH was only used for WINDOWS servers?
I'm *pretty sure* our ENV VARS for the LIBs and server correctly-
because before we set them we were getting a DIFFERENT error (cant load
Oracle.so). Now we're past that error onto the next one. So I think the
ORACLE_HOME and LD paths are OK now.
Its a preplexing problem with LOTS and LOTS of difffernt proposed fixes
in the forums. I suspect that's because there are so many possible problems.
As a programmer, I'm not dazzled by the error message. I would never
present my users with a message like "it might be A, or possibly B, or
something to do with C, or possibly SOMETHING ELSE"..
Instead I would CHECK A, report an A error if found,. Check B, report a
B error if found. And so on. Its unreasonable to expect a user to react
to a message that basically says IT COULD BE ANYTHING!
In this case, some users say check the locale, language settings, others
say check LIB PATH. Others say its a DBI or DBD / Oracle version
mismatch. SOme say its an Oracle 10 security issue and I need to run an
Oracle script to un-harden it?
I've encountered very few times in my 20 years as a programmer where ONE
error could be caused by so many possibilities. After like 4 man-weeks,
we're still fumbling with it.
Thanks!
MP
On Wed, Apr 7, 2010 at 4:53 PM, Alexander Foken <alexan...@foken.de
<mailto:alexan...@foken.de>> wrote:
On 07.04.2010 10:45, Martin Evans wrote:
Perl Diety wrote:
ENV VARS
DOCUMENT_ROOT = /var2/www/html
GATEWAY_INTERFACE = CGI/1.1
HTTP_ACCEPT = */*
HTTP_ACCEPT_ENCODING = gzip, deflate
HTTP_ACCEPT_LANGUAGE = en-us
HTTP_HOST = ournode.com <http://ournode.com>
HTTP_UA_CPU = x86
HTTP_USER_AGENT = Mozilla/4.0
LD_LIBRARY_PATH = /export/apps/oracle/product/10201/lib
LD_RUN_PATH = /export/apps/oracle/product/10201/lib
NLS_LANG = en_GB.UTF-8
ORACLE_BASE = /export/apps/oracle
ORACLE_HOME = /export/apps/oracle/product/10201
ORA_NLS10 = /export/apps/oracle/product/10201/nls/data/
REQUEST_METHOD = GET
REQUEST_URI = /cgi-bin/oratest.cgi
SERVER_PORT = 80
SERVER_PROTOCOL = HTTP/1.1
SERVER_SIGNATURE =
Apache/2.0.52 (Red Hat) Server at ournode.com
<http://ournode.com> Port 80
SERVER_SOFTWARE = Apache/2.0.52 (Red Hat)
DBI connect(...) failed: ERROR OCIEnvNlsCreate. Check
ORACLE_HOME (Linux)
env var or PATH (Windows) and or NLS settings, permissions,
etc. at
/cgi-bin/oratest.cgi line 32
This looks roughly like a CGI enviromnent, and the Oracle Variables
seem to be set. But lots of variables seem to be missing, like PATH
and some variabes starting with HTTP_, SERVER_, SCRIPT_, and
REQUEST_. And the LD_xxx variables shouldn't be there.
If this is the *complete* environment provided to the CGI, something
is *very* wrong with the Apache.
If not, post a complete dump of %ENV in CGI context, e.g. with the
printenv script that came with Apache:
#!/usr/local/bin/perl
##
## printenv -- demo CGI program which just prints its environment
##
print "Content-type: text/plain; charset=iso-8859-1\n\n";
foreach $var (sort(keys(%ENV))) {
$val = $ENV{$var};
$val =~ s|\n|\\n|g;
$val =~ s|"|\\"|g;
print "${var}=\"${val}\"\n";
}
Did you really set AND export ORACLE_HOME or LD_LIBRARY_PATH
such that
Apache children see them? I can't remember what the syntax in the
httpd.conf file is now (SetEnv perhaps) as I no longer use
Apache but
you used to have to explicitly tell Apache which env vars to allow.
Martin
Two ways:
1. PassEnv VariableName [...] -- see
<http://httpd.apache.org/docs/2.2/mod/mod_env.html#passenv>
2. SetEnv VariableName Value -- see
<http://httpd.apache.org/docs/2.2/mod/mod_env.html#setenv>
I prefer PassEnv over SetEnv when the variables already exist in the
environment of the process invoking the Apache server. That way, I
don't have to change the Apache configuration when an environment
variable changes. I use SetEnv only to set additional variables that
must not appear in the environment of the process invoking the
Apache server.
See also
<http://alexander-foken.de/Censored%20copy%20of%20Oracle%20Troubleshooter%20HOWTO.html>
Alexander
--
Alexander Foken
mailto:alexan...@foken.de <mailto:alexan...@foken.de>
http://www.foken.de/alexander/
--
Alexander Foken
mailto:alexan...@foken.de http://www.foken.de/alexander/
