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?
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.
This should be solved using proper SSO with roles, so that password will not be required, see bug#1055182.
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
We should be able to add this using this util: https://github.com/ovirt-china/engine-reports-config-passwd
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.
Following comment #6, I was advised by didi to consult with bazulay and sradco if we can close this bug.
(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.
(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.
(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?
(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.
(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.
(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.
(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?
Can you please reply to comment #14, if this is not in 3.6, I would want to introduce this RFE.
(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.
Due to comment #16, please include this item in the coming weekathon.
Can you add the BZ to the commit?
(In reply to Yaniv Dary from comment #18) > Can you add the BZ to the commit? It's a private bug.
ovirt-3.6.0-3 release
For documentation please see bug 1198107 comment 7.
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.
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.
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
(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.
Thanks Verified in ovirt-engine-reports-3.6.0-0.0.master.20150624094644.20150624094424.git019fd83.el6.noarch
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