subject:"\[ovirt\-users\] Re\: LDAP Authentication issues"

[ovirt-users] Re: LDAP Authentication issues

2018-06-12 Thread Callum Smith

Dear All,

Seems the required element for the CPU Profile to work is in roles_groups table:

insert into roles_groups (role_id, action_group_id) VALUES
('def00017----def00017', '1668');

Whether the action_group_id is install-specific or not is unclear, but the role
UUID for "CPUOperator" should be standard.

Regards,
Callum

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 12 Jun 2018, at 09:47, Callum Smith
mailto:cal...@well.ox.ac.uk>> wrote:

Dear All,

Process of database "fixing" is required because adding system permissions to
the "Everyone" group is a one-way process that causes many problems and there
is no way to rescue from the GUI, only options are to restore from backup or
rebuild the permissions database.

The next issue, is that CPU Profiles are locked out to even the SuperUser - so
creating a VM with the SuperUser account with reset permissions is denied:
User doesn't have permissions to assign the cpu profile Default with id
58ca604e-01a7-003f-01de-0250 to VMs.

I consider that to be a bug, personally, as a SuperUser should have access to
everything by definition.

To solve this in the mean time, i need to know the object_type_id of a cpu
profile to manually reassign permissions to it (you can't control CPU profile
permissions in the GUI either, only view).

Regards,
Callum

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 12 Jun 2018, at 06:44, Roy Golan
mailto:rgo...@redhat.com>> wrote:

On Tue, 12 Jun 2018 at 02:24 Donny Davis
mailto:do...@fortnebula.com>> wrote:
I am happy to help where I can. I would also not recommend tinkering around in
the database, but I am happy to hear you have it all running. :)

Everything you should every be doing in the engine is available via the API/UI.
Just some general advice.

On Mon, Jun 11, 2018 at 9:31 AM, Callum Smith
mailto:cal...@well.ox.ac.uk>> wrote:
Dear All & Donny,

Thank you for the clarifications, very useful indeed.

A note for future users who go down this path and dont want to restore or
reinstall:

Cleaning out the `permissions` table in the database and restoring the defaults
will solve the issue, but you need to restore the SuperUser permission on the
admin@internal account:

Learning from here:
https://www.ovirt.org/develop/developer-guide/action-permissions-overview/

Clean out your `roles_groups` and `permissions`
DELETE FROM `permissions`;
DELETE FROM `roles_groups`;

Restore the defaults:
https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/data/00600_insert_permissions.sql
https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/data/00700_insert_roles_groups.sql

Re-assign the SuperUser role to the admin@internal user:
Either:
https://github.com/oVirt/ovirt-engine/blob/master/packaging/bin/ovirt-engine-role.sh
Or just go straight into your localhost psql on your engine, replacing
information as appropriate:
Get your external_id from the users table and use it in the function:
SELECT external_id FROM `users` WHERE `name` = 'admin' AND `domain` =
'internal-authz';
select
attach_user_to_role('admin','internal-authz','*','#external_id#','SuperUser');

Regards,
Callum

I think the root cause here is that you are trying to login to the webadmin and
not the vm portal. User are authorized to login to the web admin
only if they have a role of type 'admin'. And UserRole is a 'user' type. So the
solution is not the give SuperUser for all those users, this is just a
workaround.

If you want to know for sure, go to Administration - Configure - Roles.

So ask yourself why users need access to the webadmin at all. If they need
admin permission assign them an appropriate role on the DC or the cluster.
If not, they use the VM portal.

Having said all that, if nothing helps and the db needs 'fixing' (I doubt it
though) then this is a bug.
--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:57, Donny Davis
mailto:do...@fortnebula.com>> wrote:

https://lists.ovirt.org/pipermail/users/2015-January/030981.html

This is the thread where I discussed a bit of the permissions thing. I am sure
things have changed since 3.5.1, but should get you down the right path.

On Mon, Jun 11, 2018 at 6:54 AM, Callum Smith
mailto:cal...@well.ox.ac.uk>> wrote:
Yes, in process of trying to fix/identify things - need to undo this.

Regards,
Callum

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:48, Donny Davis
mailto:do...@fortnebula.com>> wrote:

did you add system permissions to the everyone group?

[ovirt-users] Re: LDAP Authentication issues

2018-06-12 Thread Callum Smith

Yes indeed

Regards,
Callum

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 12 Jun 2018, at 10:18, Roy Golan
mailto:rgo...@redhat.com>> wrote:

On Tue, 12 Jun 2018 at 11:48 Callum Smith
mailto:cal...@well.ox.ac.uk>> wrote:
Dear All,

I consider that to be a bug, personally, as a SuperUser should have access to
everything by definition.

Is that user is admin@internal?