Bug 1139211 - Automatic provisioning ignores db password supplied in answer file
Summary: Automatic provisioning ignores db password supplied in answer file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup
Version: 3.4.0
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: ---
: 3.4.3
Assignee: Simone Tiraboschi
QA Contact: sefi litmanovich
URL:
Whiteboard: integration
Depends On: 1133621
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-08 12:02 UTC by rhev-integ
Modified: 2014-10-23 12:30 UTC (History)
15 users (show)

Fixed In Version: org.ovirt.engine-root-3.4.3-1
Doc Type: Bug Fix
Doc Text:
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.
Clone Of: 1133621
Environment:
Last Closed: 2014-10-23 12:30:41 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1712 0 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.4.3 update 2014-10-23 16:29:47 UTC
oVirt gerrit 32036 0 master MERGED packaging: setup: honouring engine DB parameters from answer file Never
oVirt gerrit 32041 0 ovirt-engine-3.5 MERGED packaging: setup: honouring engine DB parameters from answer file Never
oVirt gerrit 32067 0 ovirt-engine-3.4 MERGED packaging: setup: honouring engine DB parameters from answer file Never
oVirt gerrit 32646 0 master MERGED packaging: setup: Avoid engine DB password in answerfile if providing Never
oVirt gerrit 32649 0 ovirt-engine-3.5 MERGED packaging: setup: Avoid engine DB password in answerfile if providing Never
oVirt gerrit 32651 0 ovirt-engine-3.4 MERGED packaging: setup: Avoid engine DB password in answerfile if providing Never

Comment 1 Yedidyah Bar David 2014-09-08 12:11:41 UTC 
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.
Comment 3 sefi litmanovich 2014-10-02 14:10:21 UTC 
Verified with rhevm-setup-3.4.3-1.1.el6ev.noarch.

generated an answer file with db credentials (username, database name, self defined password) and: OVESETUP_PROVISIONING/postgresProvisioningEnabled=bool:True

ran engine-setup with this answer file, setup was successful, tried to connect to DB with my defined password was successful as well:
 
export PGPASSWORD=mypass; psql -d engine -U engine -h localhost -t -A -c '--'
Comment 4 Yedidyah Bar David 2014-10-23 10:42:28 UTC 
Julie, not sure the doctext as-is is good enough.

engine-setup was also changed to not keep the password in the answer file if automatic provisioning was selected.

This means that by default, we keep the previous behavior:

running engine-setup with automatic provisioning creates a random password, and creates an answer file. If this answer file is used to run engine-setup, it will create another random password.

The way this works:

Before this bug/fix - because if setup does auto provisioning, a password in the answer file is ignored

After this bug/fix - because setup does not write the password to the generated answer file.

The flow that changed is - running setup with an answer file that asks for auto provisioning and supplies a password. This flow can happen by either using an answer file generated by an older setup (not containing this fix) or by manually editing the answer file and adding a password.
Comment 6 errata-xmlrpc 2014-10-23 12:30:41 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2014-1712.html
Note You need to log in before you can comment on or make changes to this bug.