Bug 501022

Summary:	TNS_ADMIN ignored by python scripts
Product:	[Community] Spacewalk	Reporter:	Jason Czerak <czerakj>
Component:	Server	Assignee:	Michael Mráka <mmraka>
Status:	CLOSED WORKSFORME	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	low
Version:	0.5	CC:	cperry, mmraka
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-02-05 17:30:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	559281

Description Jason Czerak 2009-05-15 14:29:30 UTC

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 16:17:43 UTC

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 14:30:20 UTC

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 14:50:49 UTC

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 14:34:57 UTC

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 17:27:56 UTC

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 17:30:00 UTC

Closing. Fell free to reopen if you have an additional info.

Comment 7 Jason Czerak 2010-02-05 18:46:52 UTC

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.