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:
Hi Jason, AFAIK there is no code which is looking for tnsnames.ora in /etc. Could you be more specific?
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.
I probably don't understand. Could you give me an exact example what you type, what you expect and what you get?
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.
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
Closing. Fell free to reopen if you have an additional info.
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.