Bug 589055

Summary:	spacewalk-setup should not try to overwrite /etc/tnsnames.ora in case it exists
Product:	[Community] Spacewalk	Reporter:	Milan Zázrivec <mzazrivec>
Component:	Installation	Assignee:	Jan Pazdziora <jpazdziora>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	low
Version:	1.0	CC:	mmraka
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	spacewalk-setup-1.3.7-1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-02-08 08:42:03 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:	653453

Description Milan Zázrivec 2010-05-05 09:19:19 UTC

Description of problem:
spacewalk-setup in oracle_setup_db_connection() overwrites /etc/tnsnames.ora
regardless of whether the file exists or not. This does not seem to
be necessary, since:
1. in Spacewalk installations, the file is created manually before
the user calls spacewalk-setup
2. during upgrades, the file exists before the upgrade and in certain
scenarios (umask set specifically) the overwritten file will have
incorrect permissions.

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

How reproducible:
Always

Steps to Reproduce:
1. set umask to something funny
2. upgrade from previous spacewalk
  
Actual results:
Wrong permissions on /etc/tnsnames.ora

Expected results:
File won't be overwritten in case it exists.

Additional info:
N/A

Comment 1 Jan Pazdziora 2010-05-05 10:21:40 UTC

Michael, do we have any plans to get rid of tnsnames.ora completely?

Comment 2 Jan Pazdziora 2010-11-19 16:05:45 UTC

Mass-moving to space13.

Comment 3 Jan Pazdziora 2011-01-28 09:01:26 UTC

Addressed in Spacewalk master, 11df63a4baf949231d1fb52fabf41c64b0753c77. From the commit message:

    Refactored oracle_get_database_answers.
    
    We do not want to ask for username and password before we know
    what database we talk to.
    
    Also, we no longer create/change /etc/tnsnames.ora.
    
    The db-name in answer file can either refer to service name
    at db-host (//db-host(:db-port)/db-name) or to a service name
    specified in tnsnames.ora. This allows the user to set anything
    in their tnsnames.ora before running spacewalk-setup (think RAC
    and any advanced options) and just use it.
    
    For similar reason, db-protocol is no longer supported.

Comment 4 Tomas Lestach 2011-02-03 12:21:39 UTC

Moving ON_QA ...

Comment 5 Tomas Lestach 2011-02-08 08:42:03 UTC

This bug has been fixed in Spacewalk 1.3.