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
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: 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.
Moving ON_QA ...
This bug has been fixed in Spacewalk 1.3.