Bug 589055 - spacewalk-setup should not try to overwrite /etc/tnsnames.ora in case it exists
spacewalk-setup should not try to overwrite /etc/tnsnames.ora in case it exists
Product: Spacewalk
Classification: Community
Component: Installation (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Jan Pazdziora
Red Hat Satellite QA List
Depends On:
Blocks: space13
  Show dependency treegraph
Reported: 2010-05-05 05:19 EDT by Milan Zázrivec
Modified: 2011-02-08 03:42 EST (History)
1 user (show)

See Also:
Fixed In Version: spacewalk-setup-1.3.7-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-08 03:42:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Milan Zázrivec 2010-05-05 05:19:19 EDT
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:

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:
Comment 1 Jan Pazdziora 2010-05-05 06:21:40 EDT
Michael, do we have any plans to get rid of tnsnames.ora completely?
Comment 2 Jan Pazdziora 2010-11-19 11:05:45 EST
Mass-moving to space13.
Comment 3 Jan Pazdziora 2011-01-28 04:01:26 EST
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 07:21:39 EST
Moving ON_QA ...
Comment 5 Tomas Lestach 2011-02-08 03:42:03 EST
This bug has been fixed in Spacewalk 1.3.

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