Bug 1032646 - [RHEVM-SETUP] - Remote db user is incorrectly configured in setup
[RHEVM-SETUP] - Remote db user is incorrectly configured in setup
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup (Show other bugs)
3.2.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.2.6
Assigned To: Ofer Schreiber
Jiri Belka
integration
: TestOnly, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-20 09:17 EST by Barak Dagan
Modified: 2014-02-09 18:30 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-09 18:30:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
engine-setup_2013_11_19_20_05_37.log (10.22 KB, application/x-tar-gz)
2013-11-20 09:17 EST, Barak Dagan
no flags Details

  None (edit)
Description Barak Dagan 2013-11-20 09:17:40 EST
Created attachment 826662 [details]
engine-setup_2013_11_19_20_05_37.log

Description of problem:
dwh setup asked for remote user, but accept only the default postgres user:

Enter the host IP or host name where RHEV Manager DB is running: fire32-remdb.scl.lab.tlv.redhat.com
Enter the DB port number  [5432] :
Enter the remote DB user name  [postgres] : engine
Enter the password for the remote DB user :
Warning: Weak Password.
Confirm password :
Configure a secure connection? (make sure SSL is configured on the remote DB server) ['yes'| 'no']  [no] : no

Couldn't create temp database on server fire32-remdb.scl.lab.tlv.redhat.com. Check provided credentials.


Entering a remote RHEV Manager DB configuration section. All the configuration parameters should be provided by the remote DB administrator.
Enter the host IP or host name where RHEV Manager DB is running: fire32-remdb.scl.lab.tlv.redhat.com
Enter the DB port number  [5432] :
Enter the remote DB user name  [postgres] :
Enter the password for the remote DB user :
Warning: Weak Password.
Confirm password :
Configure a secure connection? (make sure SSL is configured on the remote DB server) ['yes'| 'no']  [no] :
Configure NFS share on this server to be used as an ISO Domain? ['yes'| 'no']  [yes] : 

Version-Release number of selected component (if applicable):
3.2.4, sf21.1

How reproducible:
100%

Steps to Reproduce:
1. prepare remote db vm
2. create new role in db (engine):
psql -U postgres -c "create user engine password 'engine';"
3. try to use that user in dwh-setup

Actual results:
userfails. only postgres user can be used after altering that user with a new password (postgres)

Expected results:
use the user entered

Additional info:
Comment 3 Arthur Berezin 2013-11-21 12:00:25 EST
Barak, what is the BZ# for the fix in 3.3 so we could clone it?
Comment 4 Barak Dagan 2013-11-21 12:09:18 EST
(In reply to Arthur Berezin from comment #3)
> Barak, what is the BZ# for the fix in 3.3 so we could clone it?

Arthur, I'm not sure that the is on for 3.3. 3.3 setup was refactored using otopi, that issue might be fixed then. I find that issue in 3.2 while preparing some remote enviourments. If it is worth fixing in that version, I need 3.2.z flag set, as I don't such permissions.
Comment 5 Sandro Bonazzola 2013-12-12 04:57:58 EST
Setting 3.2.z flag, targeting to 3.2.6.
It works on 3.3.0 so no code change, TestOnly on 3.3.0
Comment 6 Barak Dagan 2013-12-18 07:12:19 EST
(In reply to Barak Dagan from comment #0)
> Created attachment 826662 [details]
> engine-setup_2013_11_19_20_05_37.log
> 
> Description of problem:
> dwh setup asked for remote user, but accept only the default postgres user:
> 
> Enter the host IP or host name where RHEV Manager DB is running:
> fire32-remdb.scl.lab.tlv.redhat.com
> Enter the DB port number  [5432] :
> Enter the remote DB user name  [postgres] : engine
> Enter the password for the remote DB user :
> Warning: Weak Password.
> Confirm password :
> Configure a secure connection? (make sure SSL is configured on the remote DB
> server) ['yes'| 'no']  [no] : no
> 
> Couldn't create temp database on server fire32-remdb.scl.lab.tlv.redhat.com.
> Check provided credentials.
> 
> 
> Entering a remote RHEV Manager DB configuration section. All the
> configuration parameters should be provided by the remote DB administrator.
> Enter the host IP or host name where RHEV Manager DB is running:
> fire32-remdb.scl.lab.tlv.redhat.com
> Enter the DB port number  [5432] :
> Enter the remote DB user name  [postgres] :
> Enter the password for the remote DB user :
> Warning: Weak Password.
> Confirm password :
> Configure a secure connection? (make sure SSL is configured on the remote DB
> server) ['yes'| 'no']  [no] :
> Configure NFS share on this server to be used as an ISO Domain? ['yes'|
> 'no']  [yes] : 
> 
> Version-Release number of selected component (if applicable):
> 3.2.4, sf21.1
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. prepare remote db vm
> 2. create new role in db (engine):
> psql -U postgres -c "create user engine password 'engine';"
> 3. try to use that user in dwh-setup
> 
> Actual results:
> userfails. only postgres user can be used after altering that user with a
> new password (postgres)
> 
> Expected results:
> use the user entered
> 
> Additional info:


This BZ was opened in front of engine-setup installation on 3.2 . The dwh-setup was mentioned by mistake
Comment 7 Tareq Alayan 2014-01-06 07:43:43 EST
what to test here?
Comment 8 Barak Dagan 2014-01-15 07:38:04 EST
The Bug is about using non postgres role for engine setup - on remote db.
Currently - in 3.2, the setup asks for remote user, having postgres as default answer, and fails if that user is not postgres.

The steps to reproduce are to create another role on the remote db server, and use it's credentials during setup.
Comment 9 Jiri Belka 2014-02-05 04:01:41 EST
ok, rhevm-setup-3.3.0-0.46.el6ev.noarch. Tested with remote DB - testengine/testengine.
Comment 10 Itamar Heim 2014-02-09 18:30:39 EST
this was fixed for 3.3.

Note You need to log in before you can comment on or make changes to this bug.