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.
Is that user is admin@internal?
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. callum(a)well.ox.ac.uk
On 12 Jun 2018, at 06:44, Roy Golan <rgolan(a)redhat.com> wrote:
On Tue, 12 Jun 2018 at 02:24 Donny Davis <donny(a)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 <callum(a)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/dat...
>>
>>
https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/dat...
>>
>> Re-assign the SuperUser role to the admin@internal user:
>> Either:
>>
https://github.com/oVirt/ovirt-engine/blob/master/packaging/bin/ovirt-eng...
>> 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. callum(a)well.ox.ac.uk
>>
>> On 11 Jun 2018, at 11:57, Donny Davis <donny(a)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 <callum(a)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. callum(a)well.ox.ac.uk
>>>
>>> On 11 Jun 2018, at 11:48, Donny Davis <donny(a)fortnebula.com> wrote:
>>>
>>> did you add system permissions to the everyone group?
>>>
>>> On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith <callum(a)well.ox.ac.uk>
>>> 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. callum(a)well.ox.ac.uk
>>>>
>>>> On 11 Jun 2018, at 11:38, Donny Davis <donny(a)fortnebula.com>
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
<callum(a)well.ox.ac.uk>
>>>> 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. callum(a)well.ox.ac.uk
>>>>>
>>>>> On 11 Jun 2018, at 11:29, Callum Smith <callum(a)well.ox.ac.uk>
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. callum(a)well.ox.ac.uk
>>>>>
>>>>> On 11 Jun 2018, at 11:26, Donny Davis <donny(a)fortnebula.com>
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
<callum(a)well.ox.ac.uk>
>>>>> 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. callum(a)well.ox.ac.uk
>>>>>>
>>>>>> On 11 Jun 2018, at 11:21, Donny Davis
<donny(a)fortnebula.com> 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
<callum(a)well.ox.ac.uk>
>>>>>> 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...
>>>>>>>
>>>>>>> Regards,
>>>>>>> Callum
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Callum Smith
>>>>>>> Research Computing Core
>>>>>>> Wellcome Trust Centre for Human Genetics
>>>>>>> University of Oxford
>>>>>>> e. callum(a)well.ox.ac.uk
>>>>>>>
>>>>>>> On 11 Jun 2018, at 09:35, Callum Smith
<callum(a)well.ox.ac.uk>
>>>>>>> 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. callum(a)well.ox.ac.uk
>>>>>>>
>>>>>>> On 5 Jun 2018, at 11:42, Callum Smith
<callum(a)well.ox.ac.uk> 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. callum(a)well.ox.ac.uk
>>>>>>>
>>>>>>> On 5 Jun 2018, at 10:14, Callum Smith
<callum(a)well.ox.ac.uk> 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 =
>>>>>>> _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 =
bmrc-resolve-groups
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Callum
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Callum Smith
>>>>>>> Research Computing Core
>>>>>>> Wellcome Trust Centre for Human Genetics
>>>>>>> University of Oxford
>>>>>>> e. callum(a)well.ox.ac.uk
>>>>>>>
>>>>>>> On 4 Jun 2018, at 15:07, Callum Smith
<callum(a)well.ox.ac.uk> 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. callum(a)well.ox.ac.uk
>>>>>>>
>>>>>>> On 29 May 2018, at 11:29, Ondra Machacek
<omachace(a)redhat.com>
>>>>>>> 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
<callum(a)well.ox.ac.uk>
>>>>>>> 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. callum(a)well.ox.ac.uk
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>>>> 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/users@ovirt.org/message/NAEUHLW3YMY...
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>>>> 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/users@ovirt.org/message/2WR4PGLW4Z4...
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>>>> 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/users@ovirt.org/message/O7DLMLFEBHL...
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>>>> 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/users@ovirt.org/message/BNZ5KRXOYYR...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>>>> 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/users@ovirt.org/message/EOWAPL6ZQE6...
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> _______________________________________________
> Users mailing list -- users(a)ovirt.org
> To unsubscribe send an email to users-leave(a)ovirt.org
> 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/users@ovirt.org/message/3PEP2BOH74Q...