+++ This bug was initially created as a clone of Bug #1332892 +++ +++ This bug was initially created as a clone of Bug #1133621 +++ Description of problem: [ INFO ] Stage: Misc configuration [ INFO ] Creating Engine database schema [ ERROR ] Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/dbscripts/create_schema.sh' failed to execute [ INFO ] Yum Performing yum transaction rollback [ INFO ] Rolling back database schema [ INFO ] Clearing Engine database engine [ ERROR ] Engine database rollback failed: FATAL: password authentication failed for user "engine" FATAL: password authentication failed for user "engine" Version-Release number of selected component (if applicable): av11.1 How reproducible: 100%, automatically and manually Steps to Reproduce: 1. rhevm-setup --config-append=working 2. rhevm-cleanup --config-append=cleanup 3. rhevm-setup --config-append=setup Actual results: Expected results: Additional info: Found by automated testing, probably introduced with av11.1 --- Additional comment from Petr Beňas on 2014-08-25 18:05:48 IDT --- --- Additional comment from Petr Beňas on 2014-08-25 18:06:11 IDT --- --- Additional comment from Petr Beňas on 2014-08-25 18:07:04 IDT --- --- Additional comment from Petr Beňas on 2014-08-25 18:08:03 IDT --- [root@localhost ~]# tail /var/lib/pgsql/data/pg_hba.conf # TYPE DATABASE USER CIDR-ADDRESS METHOD # "local" is for Unix domain socket connections only local all all ident host engine engine 0.0.0.0/0 md5 host engine engine ::0/0 md5 # IPv4 local connections: host all all 127.0.0.1/32 ident # IPv6 local connections: host all all ::1/128 ident --- Additional comment from Petr Beňas on 2014-08-25 19:26:11 IDT --- Found simplier reproducing vector: [ INFO ] Execution of setup completed successfully [root@localhost ~]# export PGPASSWORD=123456; psql -d engine -U engine -h localhost -t -A -c '--' psql: FATAL: password authentication failed for user "engine" [root@localhost ~]# history | tail -n 5 5 2014-08-25 18:19:22 hostname 6 2014-08-25 18:19:32 vim working 7 2014-08-25 18:19:53 rhevm-setup --config-append=working 8 2014-08-25 18:24:16 export PGPASSWORD=123456; psql -d engine -U engine -h localhost -t -A -c '--' 9 2014-08-25 18:24:51 history | tail -n 5 --- Additional comment from David Caro on 2014-08-25 20:10:40 IDT --- The bug is actually that setting the postgres provisioning to true, generates the database password even if it was specified in the answerfile, changing the option: OVESETUP_PROVISIONING/postgresProvisioningEnabled=bool:True to OVESETUP_PROVISIONING/postgresProvisioningEnabled=bool:False in the first setup answerfile works as expected. --- Additional comment from Petr Beňas on 2014-08-26 11:07:34 IDT --- I don't see any change in behaviour when trying postgresProvisioning set to False.... http://jenkins.qa.lab.tlv.redhat.com:8080/view/RhevmCore/view/3.4-All/job/3.4-git-rhevmCore-infra_tools_setup/29/console --- Additional comment from Petr Beňas on 2014-08-26 13:42:09 IDT --- Tried manually running on freshly installed system with the OVESETUP_PROVISIONING/postgresProvisioningEnabled=bool:False and got following result. It looks one would have to create the db manually in such case. INFO ] Creating Engine database schema [ ERROR ] Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/dbscripts/create_schema.sh' failed to execute [ INFO ] Yum Performing yum transaction rollback [ INFO ] Rolling back database schema [ INFO ] Clearing Engine database engine [ ERROR ] Engine database rollback failed: could not connect to server: Connection refused Is the server running on host "localhost" and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused Is the server running on host "localhost" and accepting TCP/IP connections on port 5432? So my guess is that if OVESETUP_PROVISIONING/postgresProvisioningEnabled=bool:True is set, the password from answerfile is ignored and new password is generated. --- Additional comment from Yedidyah Bar David on 2014-09-08 15:10:39 IDT --- As discussed, we should also refrain from writing to the answer file the randomly-generated password. This way, mere use of setup-generated answer file will keep the existing behavior (generate a new password), while special cases will still be able to supply their own password even if auto provisioning. --- Additional comment from Eyal Edri on 2014-09-11 00:29:04 IDT --- bug fixed in vt3. if you think it's not included in latest build, please contact rhev-integ --- Additional comment from Petr Beňas on 2014-09-11 17:58:11 IDT --- in vt3 --- Additional comment from Yedidyah Bar David on 2014-10-12 12:55:00 IDT --- Simone - did you check this also on dwh/reports? --- Additional comment from Simone Tiraboschi on 2014-10-13 10:57:09 IDT --- (In reply to Yedidyah Bar David from comment #14) > Simone - did you check this also on dwh/reports? Engine DB password should now be handled correctly also installing DWH and reports, didn't try what happens with DWH and reports DB password. I'll check. --- Additional comment from Yedidyah Bar David on 2014-11-23 09:40:07 IST --- Perhaps take parts or all of the doctext from the 3.4 clone: Previously, rhevm-setup with automatic provisioning ignored a database password if one was supplied in the answer file. A new random password was generated and written to the generated answer file. Now, for automatic provisioning, if a password is supplied in the answer file, it is not ignored, and the password is not written to the answer file that is generated at the end. --- Additional comment from Yedidyah Bar David on 2016-05-04 13:06:34 IDT --- This bug happens because the fix [1] wasn't applied to dwh, which had a copy [2] of the relevant part of the code done before the fix was introduced. IMO we should stop duplicating such constants with comments "sync with XXX" without any tool/process to actually sync them. Either move all such constants to common packages that all use and do not need to copy, or create some automatic tool to verify that they are indeed synced. [1] https://gerrit.ovirt.org/#/q/I3fb9d2c10d3809c68430084f6212eaa191d5ca21,n,z [2] https://gerrit.ovirt.org/27516 --- Additional comment from Yedidyah Bar David on 2016-05-09 08:47:13 IDT --- I'd like to point out that there is no direct security issue here. If a user chooses manual provisioning, and inputs creds, including a password, these creds will be written to the answer file, by design. In the past, the password was always written, but if automatic provisioning was selected, a next run with the generated answer file ignored the password (thus creating a new random one). We then decided to stop ignoring the password, but also do not write it - so that if a user manually edits the answer file to use a specific password, it will be used. The only security issue is that a user might expect to get a newly-generated random password for each run that uses the generated answer file, which is what happens if it was generated with only the engine installed. If DWH is installed too, the file will include the password, so next runs will create a user with the same password. This is easy to notice, and fix, by deleting the relevant line from the answer file. I mainly opened this bug as a reminder to do comment 1 above - stop having duplicate constants scattered around. Doing this is likely to solve more unknown bugs, and preventing future ones. --- Additional comment from Yaniv Dary on 2016-05-23 16:18:50 IDT --- oVirt 4.0 beta has been released, moving to RC milestone. --- Additional comment from Yaniv Dary on 2016-05-23 16:25:54 IDT --- oVirt 4.0 beta has been released, moving to RC milestone. --- Additional comment from Yedidyah Bar David on 2016-06-09 17:13:53 IDT --- 58918 is for reports, pushed it just in case. Fix is in dwh, moving bug there.
Similar to cloned bug, see new summary line. Fix of this one requires the fix for the clone, thus depending on it.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
3.6 is gone EOL; Please re-target this bug to a 4.0 release.
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
verified in ovirt-engine-dwh-setup-4.1.0-1.el7ev.noarch