Bug 501022 - TNS_ADMIN ignored by python scripts
TNS_ADMIN ignored by python scripts
Status: CLOSED WORKSFORME
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
0.5
All All
low Severity medium
: ---
: ---
Assigned To: Michael Mráka
Red Hat Satellite QA List
:
Depends On:
Blocks: space09
  Show dependency treegraph
 
Reported: 2009-05-15 10:29 EDT by Jason Czerak
Modified: 2010-02-05 13:46 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-05 12:30:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jason Czerak 2009-05-15 10:29:30 EDT
Description of problem:

The use of /usr/bin/rhn-config-tnsnames.pl is not a very good idea as a default behavior. I think this functionality should be avoided in any case where "XE" is not in use. In fact doesn't XE provide a basic tnsnames.ora in it's oracle home?

In any organized datacenter folks typically do have a standard tnsnames.ora and/or tnsnames that points to ldap.  While trying to figure out why python scripts filed when I removed /etc/tnsnames.ora in favor of TNS_ADMIN export I realized the code is looking for tnsnames.ora only in /etc/. 

Version-Release number of selected component (if applicable):
0.5

How reproducible:
removed /etc/tnsnames.ora

Steps to Reproduce:
1. rm /etc/tnsnames.ora
2. start a process that uses python scripts.
3.
  
Actual results:
fails

Expected results:
works

Additional info:
Comment 1 Michael Mráka 2010-02-02 11:17:43 EST
Hi Jason,

AFAIK there is no code which is looking for tnsnames.ora in /etc. Could you be more specific?
Comment 2 Jason Czerak 2010-02-03 09:30:20 EST
If there's no code looking for tnsnames, maybe it's a pyhton bug.   the oracle perl libs look for it in /etc/

Bottom line, in order for this tool to function, it requires /etc/tnsnames.ora.

I suppose a work around could be a symlink as well.
Comment 3 Michael Mráka 2010-02-03 09:50:49 EST
I probably don't understand.
Could you give me an exact example what you type, what you expect and what you get?
Comment 4 Jason Czerak 2010-02-05 09:34:57 EST
There is nothing to type.

Has anyone run spacewalk on a non "standalone" environment before?  Where the DB might reside in an oracle RAC cluster? With RHEL 5.2 (maybe .3) version software, with out /etc/tnsnames.ora, the python scripts fail.
Comment 5 Michael Mráka 2010-02-05 12:27:56 EST
Standard setup with /etc/tnsnames.ora:

[root@xen88 ~]# ll /etc/tnsnames.ora 
-rw-r--r-- 1 root root 194 Jan 15 16:05 /etc/tnsnames.ora
[root@xen88 ~]# rlwrap sqlplus $(spacewalk-cfg-get default_db)
SQL*Plus: Release 10.2.0.4.0 - Production on Fri Feb 5 18:08:56 2010
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
SQL> Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

Move tnsnames.ora somewhere else:

[root@xen88 ~]# mkdir /etc/tns_admin
[root@xen88 ~]# mv /etc/tnsnames.ora /etc/tns_admin/
[root@xen88 ~]# rlwrap sqlplus $(spacewalk-cfg-get default_db)
SQL*Plus: Release 10.2.0.4.0 - Production on Fri Feb 5 18:10:00 2010
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
ERROR:
ORA-12154: TNS:could not resolve the connect identifier specified
Enter user-name:

Now set TNS_ADMIN:

[root@xen88 ~]# export TNS_ADMIN=/etc/tns_admin
[root@xen88 ~]# rlwrap sqlplus $(spacewalk-cfg-get default_db)
SQL*Plus: Release 10.2.0.4.0 - Production on Fri Feb 5 18:10:15 2010
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
SQL> Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0
 - Production

And check some python script:

[root@xen88 ~]# satellite-sync -l --dump-version 3.4
18:16:43 Red Hat Network Satellite - live synchronization
18:16:43    url: https://satellite.rhn.redhat.com
18:16:43    debug/output level: 1
18:16:44    db:  mim_h2/<password>@rhnsat11
18:16:44 
18:16:44 Retrieving / parsing channel-families data
18:16:46 channel-families data complete
18:16:49 
18:16:49 Retrieving / parsing channel data
18:17:28    p = previously imported/synced channel
18:17:28    . = channel not yet imported/synced
18:17:28    base-channels:
18:17:28       p rhel-i386-as-4                           7221
18:17:29       p rhel-i386-server-5                       6464
...
18:17:32 
    Import complete:
        Begin time: Fri Feb  5 18:16:43 2010
        End time:   Fri Feb  5 18:17:32 2010
        Elapsed:    0 hours, 0 minutes, 49 seconds
Comment 6 Michael Mráka 2010-02-05 12:30:00 EST
Closing. Fell free to reopen if you have an additional info.
Comment 7 Jason Czerak 2010-02-05 13:46:52 EST
I'll confirm when I can on my end.

However, run the system with TNS_ADMIN in your profiles and ensure it can still find the correct DB connections. I never ran and scripts from the command line, it didn't appear to take into account any global variables.

Note You need to log in before you can comment on or make changes to this bug.