Red Hat Bugzilla – Bug 589055
spacewalk-setup should not try to overwrite /etc/tnsnames.ora in case it exists
Last modified: 2011-02-08 03:42:03 EST
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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. set umask to something funny
2. upgrade from previous spacewalk
Wrong permissions on /etc/tnsnames.ora
File won't be overwritten in case it exists.
Michael, do we have any plans to get rid of tnsnames.ora completely?
Mass-moving to space13.
Addressed in Spacewalk master, 11df63a4baf949231d1fb52fabf41c64b0753c77. From the commit message:
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.
Moving ON_QA ...
This bug has been fixed in Spacewalk 1.3.