On Tue, 12 Jun 2018 at 11:48 Callum Smith <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-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?

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 <rgo...@redhat.com> wrote:
>
>
>
> On Tue, 12 Jun 2018 at 02:24 Donny Davis <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 <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 <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 <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 <do...@fortnebula.com> wrote:
>>>>
>>>> did you add system permissions to the everyone group?
>>>>
>>>> On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith <cal...@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. cal...@well.ox.ac.uk
>>>>>
>>>>> On 11 Jun 2018, at 11:38, Donny Davis <do...@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 <cal...@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. cal...@well.ox.ac.uk
>>>>>>
>>>>>> On 11 Jun 2018, at 11:29, Callum Smith <cal...@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. cal...@well.ox.ac.uk
>>>>>>
>>>>>> On 11 Jun 2018, at 11:26, Donny Davis <do...@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 <cal...@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. cal...@well.ox.ac.uk
>>>>>>>
>>>>>>> On 11 Jun 2018, at 11:21, Donny Davis <do...@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 <cal...@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/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. cal...@well.ox.ac.uk
>>>>>>>>
>>>>>>>> On 11 Jun 2018, at 09:35, Callum Smith <cal...@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. cal...@well.ox.ac.uk
>>>>>>>>
>>>>>>>> On 5 Jun 2018, at 11:42, Callum Smith <cal...@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. cal...@well.ox.ac.uk
>>>>>>>>
>>>>>>>> On 5 Jun 2018, at 10:14, Callum Smith <cal...@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. cal...@well.ox.ac.uk
>>>>>>>>
>>>>>>>> On 4 Jun 2018, at 15:07, Callum Smith <cal...@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. cal...@well.ox.ac.uk
>>>>>>>>
>>>>>>>> On 29 May 2018, at 11:29, Ondra Machacek <omach...@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 <cal...@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. cal...@well.ox.ac.uk
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Users mailing list -- users@ovirt.org
>>>>>>>>> To unsubscribe send an email to users-le...@ovirt.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list -- users@ovirt.org
>>>>>>>> To unsubscribe send an email to users-le...@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/NAEUHLW3YMYAP6L44RRS5MCLRU2OTXPZ/
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list -- users@ovirt.org
>>>>>>>> To unsubscribe send an email to users-le...@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/2WR4PGLW4Z4PM2UOVN4YZUJHSBRYVMOJ/
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list -- users@ovirt.org
>>>>>>>> To unsubscribe send an email to users-le...@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/O7DLMLFEBHLNCE2VCCCNNOXXGGERKAKZ/
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list -- users@ovirt.org
>>>>>>>> To unsubscribe send an email to users-le...@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/BNZ5KRXOYYRFZCQIQQU6IJVDNNBDVZSF/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list -- users@ovirt.org
>>>>>>>> To unsubscribe send an email to users-le...@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/EOWAPL6ZQE63S3732NQRH5YVJC26CQDR/
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@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/3PEP2BOH74QXB3HPKOKSH5BNCL3O4KHC/
>
>
>
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/2V4MEXOAKVPLKRLFW5DJD7JU6ENTFCVN/

Reply via email to