Bug 956226 - [RFE] Reset the RHEV-M reports admin password with rhevm-config utility.
Summary: [RFE] Reset the RHEV-M reports admin password with rhevm-config utility.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Yedidyah Bar David
QA Contact: Petr Kubica
URL:
Whiteboard:
Depends On: 1055182 1209022 1235632
Blocks: ovirt-aaa-sso 1250780
TreeView+ depends on / blocked
 
Reported: 2013-04-24 13:44 UTC by Pratik Pravin Bandarkar
Modified: 2019-04-28 09:57 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-09 20:30:46 UTC
oVirt Team: Integration
sherold: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
oVirt gerrit 42032 master MERGED packaging: Add ovirt-engine-reports-tool Never
oVirt gerrit 42411 master MERGED packaging: setup: Stop services only when needed Never
oVirt gerrit 42430 master MERGED packaging: setup: Stop services only when needed Never
Red Hat Bugzilla 1232822 None None None Never

Internal Links: 1232822

Comment 1 Itamar Heim 2013-04-28 06:36:13 UTC
while i'm for simplifying the process into a utility, rhevm-config may not be the correct one.
yaniv - if the process is complex, maybe jaspersoft should have a simple utility for this?

Comment 2 Barak 2013-05-12 12:22:46 UTC
In addition, since in the future we intend to support reports installed on a different host, rhevm-config should not be that utility.

may be a different utility is required to be executed from the host reports is installed on.

Comment 3 Alon Bar-Lev 2014-03-16 19:42:13 UTC
This should be solved using proper SSO with roles, so that password will not be required, see bug#1055182.

Comment 4 Yaniv Lavi 2014-06-23 09:36:29 UTC
Moving this for consideration for 3.6.0.
This can be done with simple script and we will help in the steps needed to reset password.



Yaniv

Comment 5 Yaniv Lavi 2015-02-01 12:33:16 UTC
We should be able to add this using this util:
https://github.com/ovirt-china/engine-reports-config-passwd

Comment 6 Alon Bar-Lev 2015-02-25 14:38:09 UTC
in 3.6 there will be no admin password for reports, as the login to sso will login to reports as well, if user has superuser role or other global role we choose he will [hopefully] be admin at repors.

Comment 7 Dudi Maroshi 2015-03-01 10:29:00 UTC
Following comment #6, I was advised by  didi@redhat.com to consult with bazulay@redhat.com and sradco@redhat.com if we can close this bug.

Comment 8 Yaniv Lavi 2015-03-01 12:02:52 UTC
(In reply to Alon Bar-Lev from comment #6)
> in 3.6 there will be no admin password for reports, as the login to sso will
> login to reports as well, if user has superuser role or other global role we
> choose he will [hopefully] be admin at repors.

We would still need maintenance users and ability to login even if engine is down, so you are not correct and we do want this feature.

Comment 9 Alon Bar-Lev 2015-03-01 12:06:36 UTC
(In reply to Yaniv Dary from comment #8)
> (In reply to Alon Bar-Lev from comment #6)
> > in 3.6 there will be no admin password for reports, as the login to sso will
> > login to reports as well, if user has superuser role or other global role we
> > choose he will [hopefully] be admin at repors.
> 
> We would still need maintenance users and ability to login even if engine is
> down, so you are not correct and we do want this feature.

ovirt-engine-reports is part of engine, the sso will be mandatory to login, this is the meaning of having sso to all engine applications.

the admin of reports is not managed, no password complexity no expiration no login via external directory, hence should go away.

it his bug kept open we won't integrate reports into engine sso, as the entire idea was to drop the usage of internal jasper users including admin.

Comment 10 Yaniv Lavi 2015-03-01 14:40:02 UTC
(In reply to Alon Bar-Lev from comment #9)
> (In reply to Yaniv Dary from comment #8)
> > (In reply to Alon Bar-Lev from comment #6)
> > > in 3.6 there will be no admin password for reports, as the login to sso will
> > > login to reports as well, if user has superuser role or other global role we
> > > choose he will [hopefully] be admin at repors.
> > 
> > We would still need maintenance users and ability to login even if engine is
> > down, so you are not correct and we do want this feature.
> 
> ovirt-engine-reports is part of engine, the sso will be mandatory to login,
> this is the meaning of having sso to all engine applications.
> 
> the admin of reports is not managed, no password complexity no expiration no
> login via external directory, hence should go away.
> 
> it his bug kept open we won't integrate reports into engine sso, as the
> entire idea was to drop the usage of internal jasper users including admin.

how would you deal with superuser role that has ultimate permissions (greater than admin) and is sometimes needed and yet breaks the integration due to paths view changes?

Comment 11 Alon Bar-Lev 2015-03-01 14:43:22 UTC
(In reply to Yaniv Dary from comment #10)
> how would you deal with superuser role that has ultimate permissions
> (greater than admin) and is sometimes needed and yet breaks the integration
> due to paths view changes?

I have no clue what you mean.

Anyway, we provide roles to users, one of the rule can be "Ultimate" the other role can be "Not ultimate", so ovirt user can be set in either.

Comment 12 Yaniv Lavi 2015-03-01 15:10:32 UTC
(In reply to Alon Bar-Lev from comment #11)
> (In reply to Yaniv Dary from comment #10)
> > how would you deal with superuser role that has ultimate permissions
> > (greater than admin) and is sometimes needed and yet breaks the integration
> > due to paths view changes?
> 
> I have no clue what you mean.
> 
> Anyway, we provide roles to users, one of the rule can be "Ultimate" the
> other role can be "Not ultimate", so ovirt user can be set in either.

I'm just not sure we will be able to switch between the roles casing anyone assigned to superuser role to not be able to use reports integration.

Comment 13 Alon Bar-Lev 2015-03-01 15:14:58 UTC
(In reply to Yaniv Dary from comment #12)
> (In reply to Alon Bar-Lev from comment #11)
> > (In reply to Yaniv Dary from comment #10)
> > > how would you deal with superuser role that has ultimate permissions
> > > (greater than admin) and is sometimes needed and yet breaks the integration
> > > due to paths view changes?
> > 
> > I have no clue what you mean.
> > 
> > Anyway, we provide roles to users, one of the rule can be "Ultimate" the
> > other role can be "Not ultimate", so ovirt user can be set in either.
> 
> I'm just not sure we will be able to switch between the roles casing anyone
> assigned to superuser role to not be able to use reports integration.

it is not switch between roles, it is adding several users to ovirt each with different roles, just like you seek to use "admin" or "ultimate admin" users to login but unmanaged.

either the application is integrated or not, if not it reduces the work of sso, well even makes it redundant, as main reason why we started it was to integrate the jasper and remove the use of local users.

Comment 14 Yaniv Lavi 2015-04-12 11:34:49 UTC
(In reply to Alon Bar-Lev from comment #13)
> (In reply to Yaniv Dary from comment #12)
> > (In reply to Alon Bar-Lev from comment #11)
> > > (In reply to Yaniv Dary from comment #10)
> > > > how would you deal with superuser role that has ultimate permissions
> > > > (greater than admin) and is sometimes needed and yet breaks the integration
> > > > due to paths view changes?
> > > 
> > > I have no clue what you mean.
> > > 
> > > Anyway, we provide roles to users, one of the rule can be "Ultimate" the
> > > other role can be "Not ultimate", so ovirt user can be set in either.
> > 
> > I'm just not sure we will be able to switch between the roles casing anyone
> > assigned to superuser role to not be able to use reports integration.
> 
> it is not switch between roles, it is adding several users to ovirt each
> with different roles, just like you seek to use "admin" or "ultimate admin"
> users to login but unmanaged.
> 
> either the application is integrated or not, if not it reduces the work of
> sso, well even makes it redundant, as main reason why we started it was to
> integrate the jasper and remove the use of local users.

When will this be introduced and the need for admin user be removed?

Comment 15 Yaniv Lavi 2015-04-28 07:30:41 UTC
Can you please reply to comment #14, if this is not in 3.6, I would want to introduce this RFE.

Comment 16 Oved Ourfali 2015-04-29 08:25:27 UTC
(In reply to Yaniv Dary from comment #14)
> (In reply to Alon Bar-Lev from comment #13)
> > (In reply to Yaniv Dary from comment #12)
> > > (In reply to Alon Bar-Lev from comment #11)
> > > > (In reply to Yaniv Dary from comment #10)
> > > > > how would you deal with superuser role that has ultimate permissions
> > > > > (greater than admin) and is sometimes needed and yet breaks the integration
> > > > > due to paths view changes?
> > > > 
> > > > I have no clue what you mean.
> > > > 
> > > > Anyway, we provide roles to users, one of the rule can be "Ultimate" the
> > > > other role can be "Not ultimate", so ovirt user can be set in either.
> > > 
> > > I'm just not sure we will be able to switch between the roles casing anyone
> > > assigned to superuser role to not be able to use reports integration.
> > 
> > it is not switch between roles, it is adding several users to ovirt each
> > with different roles, just like you seek to use "admin" or "ultimate admin"
> > users to login but unmanaged.
> > 
> > either the application is integrated or not, if not it reduces the work of
> > sso, well even makes it redundant, as main reason why we started it was to
> > integrate the jasper and remove the use of local users.
> 
> When will this be introduced and the need for admin user be removed?

Integrating reports with the new SSO framework won't fit into feature freeze for 3.6.

Comment 17 Yaniv Lavi 2015-04-29 22:00:30 UTC
Due to comment #16, please include this item in the coming weekathon.

Comment 18 Yaniv Lavi 2015-06-09 12:51:19 UTC
Can you add the BZ to the commit?

Comment 19 Yedidyah Bar David 2015-06-09 13:03:48 UTC
(In reply to Yaniv Dary from comment #18)
> Can you add the BZ to the commit?

It's a private bug.

Comment 20 Max Kovgan 2015-06-28 14:13:17 UTC
ovirt-3.6.0-3 release

Comment 21 Yedidyah Bar David 2015-06-29 11:52:32 UTC
For documentation please see bug 1198107 comment 7.

Comment 22 Petr Kubica 2015-06-29 14:57:51 UTC
For verification I'm waiting for working reports.. (bug 1235632)
First look on ovirt-engine-reports-tool looks good.. Log is without exceptions, but for now, it cannot be tested in entire scope.

Comment 23 Yedidyah Bar David 2015-07-13 09:34:16 UTC
Docs for this bug are tracked in bug 1236757.

(In reply to Petr Kubica from comment #22)
> For verification I'm waiting for working reports.. (bug 1235632)
> First look on ovirt-engine-reports-tool looks good.. Log is without
> exceptions, but for now, it cannot be tested in entire scope.

You can already run it on a separate machine. bug 1209022 is about running engine+reports in parallel.

Comment 24 Petr Kubica 2015-07-21 12:55:55 UTC
After I set the password using ovirt-engine-reports-tool, nothing changed.
User must manually restart the reportsd service to change the password.
is it okay ? 

I think: can be restarting the service included to ovirt-engine-reports-tool ? Or it would be better (for some reason) display the information message.. The change takes effect after restarting the ovirt-engine-reportsd service

Comment 25 Yedidyah Bar David 2015-07-21 13:18:36 UTC
(In reply to Petr Kubica from comment #24)
> After I set the password using ovirt-engine-reports-tool, nothing changed.
> User must manually restart the reportsd service to change the password.
> is it okay ? 
> 
> I think: can be restarting the service included to ovirt-engine-reports-tool
> ? Or it would be better (for some reason) display the information message..
> The change takes effect after restarting the ovirt-engine-reportsd service

Please see bug 1232822 for this.

For now, restart manually.

Comment 26 Petr Kubica 2015-07-22 08:36:27 UTC
Thanks

Verified in ovirt-engine-reports-3.6.0-0.0.master.20150624094644.20150624094424.git019fd83.el6.noarch

Comment 29 errata-xmlrpc 2016-03-09 20:30:46 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/RHEA-2016-0376.html


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