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-0000-0000-0000-def000000017', '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. [email protected]<mailto:[email protected]>
On 12 Jun 2018, at 09:47, Callum Smith
<[email protected]<mailto:[email protected]>> 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-000000000250 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. [email protected]<mailto:[email protected]>
On 12 Jun 2018, at 06:44, Roy Golan
<[email protected]<mailto:[email protected]>> wrote:
On Tue, 12 Jun 2018 at 02:24 Donny Davis
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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. [email protected]<mailto:[email protected]>
On 11 Jun 2018, at 11:57, Donny Davis
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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. [email protected]<mailto:[email protected]>
On 11 Jun 2018, at 11:48, Donny Davis
<[email protected]<mailto:[email protected]>> wrote:
did you add system permissions to the everyone group?
On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith
<[email protected]<mailto:[email protected]>> wrote:
Happy for you to link me a guide, googlefu is failing me.
How do i get around this "It's not allowed to remove system permissions
assigned to built-in Everyone group" - to remove permissions erroneously added.
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. [email protected]<mailto:[email protected]>
On 11 Jun 2018, at 11:38, Donny Davis
<[email protected]<mailto:[email protected]>> wrote:
You can create a profile that has the proper permissions to allow what you are
looking for, and then assign that profile to the groups you wish.
I wrote a post on this quite a while back on how to setup oVirt to appear to be
multi-tenant.
Happy to see you don't have an ldap issue :)
>This will be a problem for us to now create group permissions for all 100+
>groups since Everyone === No-one. -sigh-
On Mon, Jun 11, 2018 at 6:34 AM, Callum Smith
<[email protected]<mailto:[email protected]>> wrote:
Ah, this appears to be an issue with the proxy - setting up the spice proxy as
indicated in the guides is causing this issue, and likely will need support.
https://www.ovirt.org/documentation/admin-guide/chap-Proxies/
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. [email protected]<mailto:[email protected]>
On 11 Jun 2018, at 11:29, Callum Smith
<[email protected]<mailto:[email protected]>> wrote:
Ok, the user now logs in! This will be a problem for us to now create group
permissions for all 100+ groups since Everyone === No-one. -sigh-
A new issue, when in the VM portal as the LDAP user, i get HTTP basic auth
login prompts, and a "Authorization expired" error, then a page reload. Nothing
in the logs seem to indicate an issue.
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. [email protected]<mailto:[email protected]>
On 11 Jun 2018, at 11:26, Donny Davis
<[email protected]<mailto:[email protected]>> wrote:
Try giving your user system permissions as a superuser and see if it goes away.
I wouldn't leave it like that, but it will help isolate your issue. I don't
think you have an ldap issue... the log entry is telling you that user has no
permissions
>The user callum@Biomedical Research Computing is not authorized to perform
>login
On Mon, Jun 11, 2018 at 6:23 AM, Callum Smith
<[email protected]<mailto:[email protected]>> wrote:
Dear Donny,
No, though the user shows the permissions inherited from the Everyone group:
<Screen Shot 2018-06-11 at 11.22.42.png>
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. [email protected]<mailto:[email protected]>
On 11 Jun 2018, at 11:21, Donny Davis
<[email protected]<mailto:[email protected]>> wrote:
Just a shot in the dark, but after you setup ldap did you go in as the default
admin and give an ldap account permissions?
On Mon, Jun 11, 2018 at 6:04 AM, Callum Smith
<[email protected]<mailto:[email protected]>> wrote:
Dear All,
Could this be as our LDAP is fairly short on attributes?
2018-06-11 11:00:52,856+01 INFO
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-5)
[5dff9eb0] Running command: CreateUserSessionCommand internal: false.
2018-06-11 11:00:52,884+01 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default
task-5) [5dff9eb0] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical
Research Computing connecting from '--ipaddr--' failed to log in<UNKNOWN>.
2018-06-11 11:00:52,884+01 ERROR
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-5) [] The
user callum@Biomedical Research Computing is not authorized to perform login
I note that a number of variables are included in this action, but which are
required and which are optional is the question:
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/aaa/src/main/java/org/ovirt/engine/core/aaa/servlet/SsoPostLoginServlet.java#L88
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. [email protected]<mailto:[email protected]>
On 11 Jun 2018, at 09:35, Callum Smith
<[email protected]<mailto:[email protected]>> wrote:
What would be the next step to help solve this issue? All users authenticating
through LDAP get "This user is not authorised to perform authentication".
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. [email protected]<mailto:[email protected]>
On 5 Jun 2018, at 11:42, Callum Smith
<[email protected]<mailto:[email protected]>> wrote:
Ok I spoke too soon, I have resolved the groups, but authentication still isn't
working for LDAP users, same error as before (114).
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. [email protected]<mailto:[email protected]>
On 5 Jun 2018, at 10:14, Callum Smith
<[email protected]<mailto:[email protected]>> wrote:
Dear Ondra, all,
Managed to solve this once i got my head around the properties file.
Conceptually the problem is that users are typically not a member of their
primary group in a POSIX scenario, and their primary group is set by the
gidNumber of the user's record, with additional group memberships specified by
memberUid entries against a posixGroup entry.
search.rfc2307-resolve-groups-memberUid.search-request.filter =
&(objectClass=posixGroup)(|(memberUid=${seq:_rfc2307_uid_encoded})(gidNumber=${seq:_rfc2307_gid_encoded}))
search.rfc2307-resolve-principal-uid.search-request.attributes = uid, gidNumber
sequence.bmrc-resolve-groups.010.description = set dn
sequence.bmrc-resolve-groups.010.type = var-set
sequence.bmrc-resolve-groups.010.var-set.variable = _rfc2307_dn
sequence.bmrc-resolve-groups.010.var-set.value = ${seq:dn}
sequence.bmrc-resolve-groups.010.description = resolve uid
sequence.bmrc-resolve-groups.020.type = fetch-record
sequence.bmrc-resolve-groups.020.fetch-record.search =
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.020.fetch-record.map.uid.name<http://sequence.bmrc-resolve-groups.020.fetch-record.map.uid.name/>
= _rfc2307_uid
sequence.bmrc-resolve-groups.030.description = resolve gid
sequence.bmrc-resolve-groups.030.type = fetch-record
sequence.bmrc-resolve-groups.030.fetch-record.search =
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.030.fetch-record.map.gidNumber.name<http://sequence.bmrc-resolve-groups.030.fetch-record.map.gidnumber.name/>
= _rfc2307_gid
sequence.bmrc-resolve-groups.040.description = query groups
sequence.bmrc-resolve-groups.040.type = search-open
sequence.bmrc-resolve-groups.040.search-open.search =
rfc2307-resolve-groups-memberUid
sequence.bmrc-resolve-groups.040.search-open.variable = queryRFC2307ByMemberUid
sequence.rfc2307-resolve-groups.020.call.name<http://sequence.rfc2307-resolve-groups.020.call.name/>
= bmrc-resolve-groups
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. [email protected]<mailto:[email protected]>
On 4 Jun 2018, at 15:07, Callum Smith
<[email protected]<mailto:[email protected]>> wrote:
Dear Ondra,
I went for openldap-rfc2307 as that best describes our ldap setup. The issue
seems to be that the gidNumber is set, but users are not a member of their
primary group within the LDAP. So, user's gidNumber represents primary group
and posixGroup membership (memberUid) represents their secondary groups. What's
the best way to approach this (fix the filters on oVirt end or change the LDAP?
This is a question of what is most compliant with standards really).
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. [email protected]<mailto:[email protected]>
On 29 May 2018, at 11:29, Ondra Machacek
<[email protected]<mailto:[email protected]>> wrote:
What's you LDAP and what profile did you choose? This looks like you have
chosen incorect profile during setup. Are you sure you arent using posix group
and using non-posix aaa profile? Sharing a debug log of
ovirt-engine-extensions-tool would be helpfull.
On Fri, May 25, 2018, 10:04 AM Callum Smith
<[email protected]<mailto:[email protected]>> wrote:
Dear All,
I'm having problems getting LDAP running, login works, but I'm getting "user is
not authorised to perform login" - this is even if i specify the UserRole
specifically to the LDAP group the user is in.
2018-05-25 08:56:16,212+01 INFO
[org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-23) [] User
callum@Biomedical Research Computing successfully logged in with scopes:
ovirt-app-admin ovirt-app-api ovirt-app-portal
ovirt-ext=auth:sequence-priority=~ ovirt-ext=revoke:revoke-all
ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search
ovirt-ext=token-info:validate ovirt-ext=token:password-access
2018-05-25 08:56:16,391+01 INFO
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-25)
[63e60fe9] Running command: CreateUserSessionCommand internal: false.
2018-05-25 08:56:16,430+01 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default
task-25) [63e60fe9] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User
callum@Biomedical Research Computing connecting from '192.168.65.254' failed to
log in<UNKNOWN>.
2018-05-25 08:56:16,430+01 ERROR
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-25) []
The user callum@Biomedical Research Computing is not authorized to perform login
on a side note: is it possible to assign permissions to all members of an LDAP
tree where they dont have a common group membership?
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. [email protected]<mailto:[email protected]>
_______________________________________________
Users mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
Users mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/[email protected]/message/NAEUHLW3YMYAP6L44RRS5MCLRU2OTXPZ/
_______________________________________________
Users mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/[email protected]/message/2WR4PGLW4Z4PM2UOVN4YZUJHSBRYVMOJ/
_______________________________________________
Users mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/[email protected]/message/O7DLMLFEBHLNCE2VCCCNNOXXGGERKAKZ/
_______________________________________________
Users mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/[email protected]/message/BNZ5KRXOYYRFZCQIQQU6IJVDNNBDVZSF/
_______________________________________________
Users mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/[email protected]/message/EOWAPL6ZQE63S3732NQRH5YVJC26CQDR/
_______________________________________________
Users mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/[email protected]/message/3PEP2BOH74QXB3HPKOKSH5BNCL3O4KHC/
_______________________________________________
Users mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/[email protected]/message/ZVEGIO7FNHAHYJBM363BP33HPWRJT2XD/
_______________________________________________
Users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/[email protected]/message/K6UAPKGNWL2MNINHTDBKNLRCAHSOK4BE/
