[Fwd: Re: failed: ERROR OCIEnvNlsCreate. Check (everything)]

-------- Original Message --------
Subject: 	Re: failed: ERROR OCIEnvNlsCreate. Check (everything)
Date: 	Thu, 8 Apr 2010 13:09:33 -0400
From: 	Perl Diety <[email protected]>
To: 	Alexander Foken <[email protected]>
References: 
<[email protected]> 
<[email protected]> <[email protected]>



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 <[email protected] 
<mailto:[email protected]>> 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:[email protected] <mailto:[email protected]>
     http://www.foken.de/alexander/



-- 
Alexander Foken
mailto:[email protected]  http://www.foken.de/alexander/