Bug 1351668

+++ 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.