[ovirt-users] Re: Problem with snapshots in illegal status

2019-02-25 Thread Bruno Rodriguez
-02-25 11:58:56,142+01 INFO
[org.ovirt.engine.core.bll.storage.lsm.LiveMigrateDiskCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-9)
[f24bee33-3e0d-4726-a9f0-9ee1c4caf063] Lock freed to object
'EngineLock:{exclusiveLocks='[0e7e53c6-ad15-484a-b084-4647b50a2567=LIVE_STORAGE_MIGRATION]',
sharedLocks=''}'
2019-02-25 11:58:56,176+01 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engineScheduled-Thread-9)
[f24bee33-3e0d-4726-a9f0-9ee1c4caf063] EVENT_ID:
USER_MOVED_DISK_FINISHED_FAILURE(2,011), User admin@internal-authz have
failed to move disk vm.example.com_Disk1 to domain PreproductionStorage01.
2019-02-25 11:59:33,685+01 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engine-Thread-23)
[b257b938-4a81-4c21-a53e-e346510d9430] EVENT_ID:
USER_REMOVE_DISK_SNAPSHOT(373), Disk 'vm.example.com_Disk1' from
Snapshot(s) 'backup_snapshot_20190217-010004' of VM 'vm.example.com'
deletion was initiated by admin@internal-authz.
2019-02-25 12:00:07,063+01 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engineScheduled-Thread-20)
[b257b938-4a81-4c21-a53e-e346510d9430] EVENT_ID:
USER_REMOVE_DISK_SNAPSHOT_FINISHED_SUCCESS(375), Disk
'vm.example.com_Disk1' from Snapshot(s) 'backup_snapshot_20190217-010004'
of VM 'vm.example.com' deletion has been completed (User:
admin@internal-authz).
You have new mail in /var/spool/mail/root


On Mon, Feb 25, 2019 at 11:52 AM Bruno Rodriguez  wrote:

> Thank you very much, Shani
>
> I've got what you asked and some good news as well. I'll start with the
> good news: the snapshots status changes to OK if I try to live-migrate the
> disk to another storage domain in the same cabin. Then I can delete them.
> Just tried with two illegal snapshots and it worked, I'll send you the
> engine logs as soon as I can check them.
>
> If I go with the query to the database (the following one) I get 0 rows
>
> # select * from images where vm_snapshot_id IN
> ('f649d9c1-563e-49d4-9fad-6bc94abc279b',
> '5734df23-de67-41a8-88a1-423cecfe7260',
> 'f649d9c1-563e-49d4-9fad-6bc94abc279b',
> '2929df28-eae8-4f27-afee-a984fe0b07e7',
> '4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f',
> 'fbaff53b-30ce-4b20-8f10-80e70becb48c',
> 'c628386a-da6c-4a0d-ae7d-3e6ecda27d6d',
> 'e9ddaa5c-007d-49e6-8384-efefebb00aa6',
> '5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4',
> '7efe2e7e-ca24-4b27-b512-b42795c79ea4');
>
> BTW, the dump-volume-chains is here. I deleted the disks with no snapshots
> in illegal status
>
> Images volume chains (base volume first)
>
>image:4dab82be-7068-4234-8478-45ec51a29bc0
>
>  - 04f7bafd-aa56-4940-9c4e-e4055972284e
>status: OK, voltype: INTERNAL, format: COW, legality:
> LEGAL, type: SPARSE
>
>  - 0fe7e3bf-24a9-45b3-9f33-9d93349b2ac1
>status: ILLEGAL, voltype: LEAF, format: COW, legality:
> ILLEGAL, type: SPARSE
>
>
>image:7428f6fd-ae2e-4691-b718-1422b1150798
>
>  - a81b454e-17b1-4c6a-a7bc-803a0e3b2b03
>status: ILLEGAL, voltype: LEAF, format: COW, legality:
> ILLEGAL, type: SPARSE
>
>
>image:c111cb15-5465-4056-b0bb-bd94565d6060
>
>  - 2443c7f2-9ee3-4a92-a80e-c3ee1a481311
>status: ILLEGAL, voltype: LEAF, format: COW, legality:
> ILLEGAL, type: SPARSE
>
>
>image:2900bc6b-3345-42a4-9533-667fb4009deb
>
>  - e9ddaa5c-007d-49e6-8384-efefebb00aa6
>status: OK, voltype: INTERNAL, format: COW, legality:
> LEGAL, type: SPARSE
>
>  - 8be46861-3d44-4dd3-9216-a2817f9d0db9
>status: ILLEGAL, voltype: LEAF, format: COW, legality:
> ILLEGAL, type: SPARSE
>
>image:79663e1f-c6a7-4193-91fa-d5cbe02f81e3
>
>  - f649d9c1-563e-49d4-9fad-6bc94abc279b
>status: OK, voltype: INTERNAL, format: COW, legality:
> LEGAL, type: SPARSE
>
>  - f0a381bb-4110-43de-999c-99ae9cb03a5a
>status: ILLEGAL, voltype: LEAF, format: COW, legality:
> ILLEGAL, type: SPARSE
>
>image:e1f3dafb-64be-46a9-a3dc-1f3f7fcd1960
>
>
>
>  - 4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f
>status: OK, voltype: INTERNAL, format: COW, legality:
> LEGAL, type: SPARSE
>
>  - 0fd199eb-ab26-46de-b0b4-b1be58d635c2
>status: ILLEGAL, voltype: LEAF, format: COW, legality:
> ILLEGAL, type: SPARSE
>
>image:fcdeeff4-1f1a-4ced-b6e9-0746c54a7fe9
>
>  - 5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4
>status: OK, voltype: INTERNAL, format: COW, legality:
> LEGAL, type: SPARSE
>
>  - c133af2a-6642-4809-b2cc-267d4cbadec9
>

[ovirt-users] Re: Problem with snapshots in illegal status

2019-02-25 Thread Bruno Rodriguez
-ba62-d6937259f097
   status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE


   image:ded89dac-ce57-4c09-8ca5-dd131e0776df

 - fbaff53b-30ce-4b20-8f10-80e70becb48c
   status: OK, voltype: INTERNAL, format: COW, legality: LEGAL,
type: SPARSE

 - 2feae690-0301-4ec3-9277-57ad3168141b
   status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE


   image:f2e35007-ff0f-4f74-90ec-1a28d342d564

 - 096faec2-e0e0-47a5-9a24-9332de963bfb
   status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE


   image:0d9b635d-22ef-4456-9b10-20be027baa7a

 - 2929df28-eae8-4f27-afee-a984fe0b07e7
   status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL,
type: PREALLOCATED

 - f65be7d6-d1bf-4db3-aa04-fd59265d5ebc
   status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE


   image:1fd83784-dc53-4f40-ac13-ac2f046aa81f

 - b413-1671-416c-bebc-3415ee7e61b2
   status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE


   image:145e5438-b7e8-45fd-81ea-3eb10a07acb6

 - baa84312-8c4e-4ac1-aa50-27836b67e5f6
   status: OK, voltype: INTERNAL, format: COW, legality: LEGAL,
type: SPARSE

 - 2a95e1fb-7e42-4589-836b-76b45f03f854
   status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE


   image:dc856555-bfef-4bfa-8351-59b5a4f04331

 - 7efe2e7e-ca24-4b27-b512-b42795c79ea4
   status: OK, voltype: INTERNAL, format: COW, legality: LEGAL,
type: SPARSE

 - a3f715c2-efc4-4421-aa4b-efce5a853e9e
   status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE


Thank you very much!!!

Bruno

On Mon, Feb 25, 2019 at 11:32 AM Shani Leviim  wrote:

> Hi Bruno,
> Can you please share the output of:
> vdsm-tool dump-volume-chains 
>
> Also, can you see those images on the 'images' table?
>
>
> *Regards,*
>
> *Shani Leviim*
>
>
> On Mon, Feb 25, 2019 at 9:32 AM Bruno Rodriguez  wrote:
>
>> Good morning, Shani
>>
>> I'm not trying to deactivate any disk because the VM using it is working.
>> I can't turn it off because I'm pretty sure if I do I won't be able to turn
>> it on again, in fact the web interface is telling me that if I turn it off
>> possibly it won't restart :(
>>
>> For what I can check I have no information about any of the the snapshots
>> I provided in the database
>>
>> engine=# select * from snapshots where snapshot_id IN
>> ('f649d9c1-563e-49d4-9fad-6bc94abc279b',
>> '5734df23-de67-41a8-88a1-423cecfe7260',
>> 'f649d9c1-563e-49d4-9fad-6bc94abc279b',
>> '2929df28-eae8-4f27-afee-a984fe0b07e7',
>> '4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f',
>> 'fbaff53b-30ce-4b20-8f10-80e70becb48c',
>> 'c628386a-da6c-4a0d-ae7d-3e6ecda27d6d',
>> 'e9ddaa5c-007d-49e6-8384-efefebb00aa6',
>> '5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4',
>> '7efe2e7e-ca24-4b27-b512-b42795c79ea4');
>>  snapshot_id | vm_id | snapshot_type | status | description |
>> creation_date | app_list | vm_configuration | _create_date | _update_date |
>> memory_volume | memory_metadata_disk_id | memory_dump_disk_id | vm_conf
>> iguration_broken
>>
>> -+---+---++-+---+--+--+--+--+---+-+-+
>> -
>> (0 rows)
>>
>>
>> Thank you
>>
>>
>> On Sun, Feb 24, 2019 at 12:16 PM Shani Leviim  wrote:
>>
>>> Hi Bruno,
>>>
>>> It seems that the disk you're trying to deactivate is in use ( Logical
>>> volume
>>> e655abce-c5e8-44f3-8d50-9fd76edf05cb/fa154782-0dbb-45b5-ba62-d6937259f097
>>> in use).
>>> Is there any task that uses that disk?
>>>
>>> Also, did you try to verify the snapshot's creation date with the DB?
>>> ( select * from snapshots; )
>>>
>>>
>>> *Regards*
>>>
>>> *Shani Leviim*
>>>
>>>
>>> On Fri, Feb 22, 2019 at 6:08 PM Bruno Rodriguez  wrote:
>>>
>>>> Hello,
>>>>
>>>> We are experiencing some problems with some snapshots in illegal status
>>>> generated with the python API. I think I'm not the only one, and that is
>>>> not a relief but I hope someone can help about it.
>>>>
>>>> I'm a bit scared because, for what I see, the creation date in the
>>>> engine for every snapshot is way differen

[ovirt-users] Re: Problem with snapshots in illegal status

2019-02-24 Thread Bruno Rodriguez
Good morning, Shani

I'm not trying to deactivate any disk because the VM using it is working. I
can't turn it off because I'm pretty sure if I do I won't be able to turn
it on again, in fact the web interface is telling me that if I turn it off
possibly it won't restart :(

For what I can check I have no information about any of the the snapshots I
provided in the database

engine=# select * from snapshots where snapshot_id IN
('f649d9c1-563e-49d4-9fad-6bc94abc279b',
'5734df23-de67-41a8-88a1-423cecfe7260',
'f649d9c1-563e-49d4-9fad-6bc94abc279b',
'2929df28-eae8-4f27-afee-a984fe0b07e7',
'4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f',
'fbaff53b-30ce-4b20-8f10-80e70becb48c',
'c628386a-da6c-4a0d-ae7d-3e6ecda27d6d',
'e9ddaa5c-007d-49e6-8384-efefebb00aa6',
'5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4',
'7efe2e7e-ca24-4b27-b512-b42795c79ea4');
 snapshot_id | vm_id | snapshot_type | status | description | creation_date
| app_list | vm_configuration | _create_date | _update_date | memory_volume
| memory_metadata_disk_id | memory_dump_disk_id | vm_conf
iguration_broken
-+---+---++-+---+--+--+--+--+---+-+-+
-
(0 rows)


Thank you


On Sun, Feb 24, 2019 at 12:16 PM Shani Leviim  wrote:

> Hi Bruno,
>
> It seems that the disk you're trying to deactivate is in use ( Logical
> volume
> e655abce-c5e8-44f3-8d50-9fd76edf05cb/fa154782-0dbb-45b5-ba62-d6937259f097
> in use).
> Is there any task that uses that disk?
>
> Also, did you try to verify the snapshot's creation date with the DB?
> ( select * from snapshots; )
>
>
> *Regards*
>
> *Shani Leviim*
>
>
> On Fri, Feb 22, 2019 at 6:08 PM Bruno Rodriguez  wrote:
>
>> Hello,
>>
>> We are experiencing some problems with some snapshots in illegal status
>> generated with the python API. I think I'm not the only one, and that is
>> not a relief but I hope someone can help about it.
>>
>> I'm a bit scared because, for what I see, the creation date in the engine
>> for every snapshot is way different from the date when it was really
>> created. The name of the snapshot is in the format
>> backup_snapshot_MMDD-HHMMSS, but as you can see in the following
>> examples, the stored date is totally random...
>>
>> Size
>> Creation Date
>> Snapshot Description
>> Status
>> Disk Snapshot ID
>>
>> 33 GiB
>> Mar 2, 2018, 5:03:57 PM
>> backup_snapshot_20190217-011645
>> Illegal
>> 5734df23-de67-41a8-88a1-423cecfe7260
>>
>> 33 GiB
>> May 8, 2018, 10:02:56 AM
>> backup_snapshot_20190216-013047
>> Illegal
>> f649d9c1-563e-49d4-9fad-6bc94abc279b
>>
>> 10 GiB
>> Feb 21, 2018, 11:10:17 AM
>> backup_snapshot_20190217-010004
>> Illegal
>> 2929df28-eae8-4f27-afee-a984fe0b07e7
>>
>> 43 GiB
>> Feb 2, 2018, 12:55:51 PM
>> backup_snapshot_20190216-015544
>> Illegal
>> 4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f
>>
>> 11 GiB
>> Feb 13, 2018, 12:51:08 PM
>> backup_snapshot_20190217-010541
>> Illegal
>> fbaff53b-30ce-4b20-8f10-80e70becb48c
>>
>> 11 GiB
>> Feb 13, 2018, 4:05:39 PM
>> backup_snapshot_20190217-011207
>> Illegal
>> c628386a-da6c-4a0d-ae7d-3e6ecda27d6d
>>
>> 11 GiB
>> Feb 13, 2018, 4:38:25 PM
>> backup_snapshot_20190216-012058
>> Illegal
>> e9ddaa5c-007d-49e6-8384-efefebb00aa6
>>
>> 11 GiB
>> Feb 13, 2018, 10:52:09 AM
>> backup_snapshot_20190216-012550
>> Illegal
>> 5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4
>>
>> 55 GiB
>> Jan 22, 2018, 5:02:29 PM
>> backup_snapshot_20190217-012659
>> Illegal
>> 7efe2e7e-ca24-4b27-b512-b42795c79ea4
>>
>>
>> When I'm getting the logs for the first one, to check what happened to
>> it, I get the following
>>
>> 2019-02-17 01:16:45,839+01 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateVolumeVDSCommand] (default
>> task-100) [96944daa-c90a-4ad7-a556-c98e66550f87] START,
>> CreateVolumeVDSCommand(
>> CreateVolumeVDSCommandParameters:{storagePoolId='fa64792e-73b3-4da2-9d0b-f334422aaccf',
>> ignoreFailoverLimit='false',
>> storageDomainId='e655abce-c5e8-44f3-8d50-9fd76edf05cb',
>> imageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f',
>> imageSizeInBytes='32212254720', volumeFormat='COW',
>> newImageId='fa154782-0dbb-45b5-ba62-d6937259f097', imageType='Sparse',
>> newImageDescription='', imageInitialSizeInBytes='0',
>> imageId='5734df23-de67-41a8-88a1-423cecfe7260',
>> sourceImageGroupId='c5cc464e-eb71-4edf-a780-60180c5

[ovirt-users] Problem with snapshots in illegal status

2019-02-22 Thread Bruno Rodriguez
Hello,

We are experiencing some problems with some snapshots in illegal status
generated with the python API. I think I'm not the only one, and that is
not a relief but I hope someone can help about it.

I'm a bit scared because, for what I see, the creation date in the engine
for every snapshot is way different from the date when it was really
created. The name of the snapshot is in the format
backup_snapshot_MMDD-HHMMSS, but as you can see in the following
examples, the stored date is totally random...

Size
Creation Date
Snapshot Description
Status
Disk Snapshot ID

33 GiB
Mar 2, 2018, 5:03:57 PM
backup_snapshot_20190217-011645
Illegal
5734df23-de67-41a8-88a1-423cecfe7260

33 GiB
May 8, 2018, 10:02:56 AM
backup_snapshot_20190216-013047
Illegal
f649d9c1-563e-49d4-9fad-6bc94abc279b

10 GiB
Feb 21, 2018, 11:10:17 AM
backup_snapshot_20190217-010004
Illegal
2929df28-eae8-4f27-afee-a984fe0b07e7

43 GiB
Feb 2, 2018, 12:55:51 PM
backup_snapshot_20190216-015544
Illegal
4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f

11 GiB
Feb 13, 2018, 12:51:08 PM
backup_snapshot_20190217-010541
Illegal
fbaff53b-30ce-4b20-8f10-80e70becb48c

11 GiB
Feb 13, 2018, 4:05:39 PM
backup_snapshot_20190217-011207
Illegal
c628386a-da6c-4a0d-ae7d-3e6ecda27d6d

11 GiB
Feb 13, 2018, 4:38:25 PM
backup_snapshot_20190216-012058
Illegal
e9ddaa5c-007d-49e6-8384-efefebb00aa6

11 GiB
Feb 13, 2018, 10:52:09 AM
backup_snapshot_20190216-012550
Illegal
5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4

55 GiB
Jan 22, 2018, 5:02:29 PM
backup_snapshot_20190217-012659
Illegal
7efe2e7e-ca24-4b27-b512-b42795c79ea4


When I'm getting the logs for the first one, to check what happened to it,
I get the following

2019-02-17 01:16:45,839+01 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.CreateVolumeVDSCommand] (default
task-100) [96944daa-c90a-4ad7-a556-c98e66550f87] START,
CreateVolumeVDSCommand(
CreateVolumeVDSCommandParameters:{storagePoolId='fa64792e-73b3-4da2-9d0b-f334422aaccf',
ignoreFailoverLimit='false',
storageDomainId='e655abce-c5e8-44f3-8d50-9fd76edf05cb',
imageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f',
imageSizeInBytes='32212254720', volumeFormat='COW',
newImageId='fa154782-0dbb-45b5-ba62-d6937259f097', imageType='Sparse',
newImageDescription='', imageInitialSizeInBytes='0',
imageId='5734df23-de67-41a8-88a1-423cecfe7260',
sourceImageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f'}), log id:
497c168a
2019-02-17 01:18:26,506+01 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand]
(default task-212) [19f00d3e-5159-48aa-b3a0-615a085b62d9] START,
GetVolumeInfoVDSCommand(HostName = hood13.pic.es,
GetVolumeInfoVDSCommandParameters:{hostId='0a774472-5737-4ea2-b49a-6f0ea4572199',
storagePoolId='fa64792e-73b3-4da2-9d0b-f334422aaccf',
storageDomainId='e655abce-c5e8-44f3-8d50-9fd76edf05cb',
imageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f',
imageId='5734df23-de67-41a8-88a1-423cecfe7260'}), log id: 111a34cf
2019-02-17 01:18:26,764+01 INFO
[org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand]
(default task-212) [19f00d3e-5159-48aa-b3a0-615a085b62d9] Successfully
added Download disk 'vm.example.com_Disk1' (id
'5734df23-de67-41a8-88a1-423cecfe7260') for image transfer command
'11104d8c-2a9b-4924-96ce-42ef66725616'
2019-02-17 01:18:27,310+01 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.AddImageTicketVDSCommand]
(default task-212) [19f00d3e-5159-48aa-b3a0-615a085b62d9] START,
AddImageTicketVDSCommand(HostName = hood11.pic.es,
AddImageTicketVDSCommandParameters:{hostId='79cbda85-35f4-44df-b309-01b57bc2477e',
ticketId='0d389c3e-5ea5-4886-8ea7-60a1560e3b2d', timeout='300',
operations='[read]', size='35433480192',
url='file:///rhev/data-center/mnt/blockSD/e655abce-c5e8-44f3-8d50-9fd76edf05cb/images/c5cc464e-eb71-4edf-a780-60180c592a6f/5734df23-de67-41a8-88a1-423cecfe7260',
filename='null'}), log id: f5de141
2019-02-17 01:22:28,898+01 INFO
[org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-100)
[19f00d3e-5159-48aa-b3a0-615a085b62d9] Renewing transfer ticket for
Download disk 'vm.example.com_Disk1' (id
'5734df23-de67-41a8-88a1-423cecfe7260')
2019-02-17 01:26:33,588+01 INFO
[org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-100)
[19f00d3e-5159-48aa-b3a0-615a085b62d9] Renewing transfer ticket for
Download disk 'vm.example.com_Disk1' (id
'5734df23-de67-41a8-88a1-423cecfe7260')
2019-02-17 01:26:49,319+01 INFO
[org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-6)
[19f00d3e-5159-48aa-b3a0-615a085b62d9] Finalizing successful transfer for
Download disk 'vm.example.com_Disk1' (id
'5734df23-de67-41a8-88a1-423cecfe7260')
2019-02-17 01:27:17,771+01 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engineScheduled-Thread-6)
[19f00d3e-5159-48aa-b3a0-615a085b62d9] EVENT_ID:

Re: [ovirt-users] Unable to rename disks via REST API

2017-06-30 Thread Bruno Rodriguez
Finally I was able to rename the disks, the problem was about handling that
put request and my inability to check libcurl documentation (I was treating
the XML I was sending as a string instead of a file).

Sorry because I needed this script to be working as fast as I could, so I
didn't try to reproduce the 500 error, but I wouldn't be suprised if it was
because of a totally wrong URL.

Sorry again :(

On Wed, Jun 28, 2017 at 1:56 PM, Juan Hernández <jhern...@redhat.com> wrote:

> On 06/28/2017 01:34 PM, Bruno Rodriguez wrote:
> > Shit, I got it. Sorry
> >
> > The problem is that I was accessing to the v4 disk-attachment id and I
> > was getting everything quite messed up. I was doing all of this while
> > creating a machine, so I was trying to rename the disk at the same time
> > it's being created.
> >
> > I'll delete all the "if ($ovirt_major == 3)" I have in my code. If I
> > have any problem I'll let you know.
> >
> > Thank you
> >
>
> If what you want to do is set the name of the disk for a VM that you are
> creating then you can just set it when adding the disk:
>
>   POST /ovirt-engine/api/vms/123/diskattachments
>
>   
> 
>   yourfavoritename
>   ...
> 
> ...
>   
>
> That way you don't need to modify it later.
>
> Also, in general, try to wait till the objects are completely created
> before trying to use or update them. For disks in particular, it is good
> idea to repeatedly retrieve the disk till the 'status' is 'OK':
>
>
> https://github.com/oVirt/ovirt-engine-sdk/blob/master/
> sdk/examples/add_vm_disk.py#L73-L80
>
> (This is an example from the Python SDK, but you get the idea. There are
> SDKs for Ruby and Java as well.)
>
> Finally, if you get a 500 error then there is most probably a bug. The
> API should never return that, even if you try to do something that
> doesn't make sense it should respond with a reasonable error message. If
> you keep getting that 500 error please share the details.
>
> > On Wed, Jun 28, 2017 at 1:03 PM, Juan Hernández <jhern...@redhat.com
> > <mailto:jhern...@redhat.com>> wrote:
> >
> > On 06/28/2017 12:55 PM, Bruno Rodriguez wrote:
> > > I'm sorry about bothering you again, but after trying it some
> times I'm
> > > still getting a "500 Internal Server Error". I'm using a REST
> client
> > > instead of CURL and I tried adding a "Version: 3" to headers and
> used
> > > the URL with the v3 as well.
> > >
> > > I'm issuing a PUT of
> > >
> > > Alias_for_disk
> > >
> > > To the URL
> > >
> > > https://myserver/ovirt-engine/api/v3/vms/62498f51-0203-48b9-
> 83c8-4c6f3bdfe05c/disks/583ed952-46a8-4bc5-8a27-8660e4a24ea2
> > <https://myserver/ovirt-engine/api/v3/vms/62498f51-
> 0203-48b9-83c8-4c6f3bdfe05c/disks/583ed952-46a8-4bc5-8a27-8660e4a24ea2>
> > >
> > > I mean, I can live without it but we are using oVirt as a "static
> > > virtualization" environment and is quite useful for us being able
> to
> > > recognize easily each disk by its server name. In case I have to
> wait
> > > until the 4.2 API version to automatize this I'll do :(
> > >
> >
> > That should work. Can you please check if you get any useful message
> in
> > /var/log/ovirt-engine/server.log or /var/log/ovirt-engine/engine.
> log?
> >
> > >
> > >
> > > On Wed, Jun 28, 2017 at 11:18 AM, Bruno Rodriguez <br...@pic.es
> <mailto:br...@pic.es>
> > > <mailto:br...@pic.es <mailto:br...@pic.es>>> wrote:
> > >
> > > Thank you very much !!!
> > >
> > > I expected I was missing something like that. Thanks again!
> > >
> > > On Wed, Jun 28, 2017 at 11:12 AM, Juan Hernández
> > > <jhern...@redhat.com <mailto:jhern...@redhat.com>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>> wrote:
> > >
> > > On 06/28/2017 10:43 AM, Bruno Rodriguez wrote:
> > > > Thank you, Daniel
> > > >
> > > > I tried a PUT with the same XML body, I got a "405
> > Method Not Allowed".
> > > > It's quite strange, there must be someting I'm missing
> > > >
> > >
> > > The operation to update a disk will be int

Re: [ovirt-users] Unable to rename disks via REST API

2017-06-28 Thread Bruno Rodriguez
Shit, I got it. Sorry

The problem is that I was accessing to the v4 disk-attachment id and I was
getting everything quite messed up. I was doing all of this while creating
a machine, so I was trying to rename the disk at the same time it's being
created.

I'll delete all the "if ($ovirt_major == 3)" I have in my code. If I have
any problem I'll let you know.

Thank you

On Wed, Jun 28, 2017 at 1:03 PM, Juan Hernández <jhern...@redhat.com> wrote:

> On 06/28/2017 12:55 PM, Bruno Rodriguez wrote:
> > I'm sorry about bothering you again, but after trying it some times I'm
> > still getting a "500 Internal Server Error". I'm using a REST client
> > instead of CURL and I tried adding a "Version: 3" to headers and used
> > the URL with the v3 as well.
> >
> > I'm issuing a PUT of
> >
> > Alias_for_disk
> >
> > To the URL
> >
> > https://myserver/ovirt-engine/api/v3/vms/62498f51-0203-48b9-
> 83c8-4c6f3bdfe05c/disks/583ed952-46a8-4bc5-8a27-8660e4a24ea2
> >
> > I mean, I can live without it but we are using oVirt as a "static
> > virtualization" environment and is quite useful for us being able to
> > recognize easily each disk by its server name. In case I have to wait
> > until the 4.2 API version to automatize this I'll do :(
> >
>
> That should work. Can you please check if you get any useful message in
> /var/log/ovirt-engine/server.log or /var/log/ovirt-engine/engine.log?
>
> >
> >
> > On Wed, Jun 28, 2017 at 11:18 AM, Bruno Rodriguez <br...@pic.es
> > <mailto:br...@pic.es>> wrote:
> >
> > Thank you very much !!!
> >
> > I expected I was missing something like that. Thanks again!
> >
> > On Wed, Jun 28, 2017 at 11:12 AM, Juan Hernández
> > <jhern...@redhat.com <mailto:jhern...@redhat.com>> wrote:
> >
> > On 06/28/2017 10:43 AM, Bruno Rodriguez wrote:
> > > Thank you, Daniel
> > >
> > > I tried a PUT with the same XML body, I got a "405 Method Not
> Allowed".
> > > It's quite strange, there must be someting I'm missing
> > >
> >
> > The operation to update a disk will be introduced in version 4
> > of the
> > API with version 4.2 of the engine. Meanwhile the way to update
> > the disk
> > is to use version 3 of the API and the disks sub-collection of
> the
> > virtual machine. That means that if you have a VM with id 123
> > and a disk
> > with id 456 you can send a request like this:
> >
> >   PUT /ovirt-engine/api/v3/vms/123/disks/456
> >
> > With a request body like this:
> >
> >   
> > newalias
> >   
> >
> > Note that you can use the above "v3" prefix in the URL or else
> the
> > "Version: 3" header. A complete example using curl:
> >
> > ---8<---
> > #!/bin/bash -ex
> >
> > url="https://.../ovirt-engine/api;
> > user="admin@internal"
> > password="..."
> > vm_id="..."
> > disk_id="..."
> >
> > curl \
> > --verbose \
> > --cacert "ca.pem" \
> > --header "Version: 3" \
> > --header "Content-Type: application/xml" \
> > --user "${user}:${password}" \
> > --request PUT \
> > --data "
> > 
> >   newalias
> > 
> > " \
> > "${url}/vms/${vm_id}/disks/${disk_id}"
> > --->8---
> >
> > >
> > > On Wed, Jun 28, 2017 at 10:07 AM, Daniel Erez <
> de...@redhat.com <mailto:de...@redhat.com>
> > > <mailto:de...@redhat.com <mailto:de...@redhat.com>>> wrote:
> > >
> > > Hi,
> > >
> > > Updating is done using the PUT method.
> > > Please try that with the same XML body.
> > >
> > > Thanks,
> > > Daniel
> > >
> > > On Wed, Jun 28, 2017 at 10:26 AM Bruno Rodriguez <
> br...@pic.es <mailto:br...@pic.es>
> > > <mailto:br...@pic.es <mailto:br...@pic.es>>> wrote:
> > >
> > > Hello everyone,
> 

Re: [ovirt-users] Unable to rename disks via REST API

2017-06-28 Thread Bruno Rodriguez
I'm sorry about bothering you again, but after trying it some times I'm
still getting a "500 Internal Server Error". I'm using a REST client
instead of CURL and I tried adding a "Version: 3" to headers and used the
URL with the v3 as well.

I'm issuing a PUT of

Alias_for_disk

To the URL

https://myserver/ovirt-engine/api/v3/vms/62498f51-0203-48b9-83c8-4c6f3bdfe05c/disks/583ed952-46a8-4bc5-8a27-8660e4a24ea2

I mean, I can live without it but we are using oVirt as a "static
virtualization" environment and is quite useful for us being able to
recognize easily each disk by its server name. In case I have to wait until
the 4.2 API version to automatize this I'll do :(



On Wed, Jun 28, 2017 at 11:18 AM, Bruno Rodriguez <br...@pic.es> wrote:

> Thank you very much !!!
>
> I expected I was missing something like that. Thanks again!
>
> On Wed, Jun 28, 2017 at 11:12 AM, Juan Hernández <jhern...@redhat.com>
> wrote:
>
>> On 06/28/2017 10:43 AM, Bruno Rodriguez wrote:
>> > Thank you, Daniel
>> >
>> > I tried a PUT with the same XML body, I got a "405 Method Not Allowed".
>> > It's quite strange, there must be someting I'm missing
>> >
>>
>> The operation to update a disk will be introduced in version 4 of the
>> API with version 4.2 of the engine. Meanwhile the way to update the disk
>> is to use version 3 of the API and the disks sub-collection of the
>> virtual machine. That means that if you have a VM with id 123 and a disk
>> with id 456 you can send a request like this:
>>
>>   PUT /ovirt-engine/api/v3/vms/123/disks/456
>>
>> With a request body like this:
>>
>>   
>> newalias
>>   
>>
>> Note that you can use the above "v3" prefix in the URL or else the
>> "Version: 3" header. A complete example using curl:
>>
>> ---8<---
>> #!/bin/bash -ex
>>
>> url="https://.../ovirt-engine/api;
>> user="admin@internal"
>> password="..."
>> vm_id="..."
>> disk_id="..."
>>
>> curl \
>> --verbose \
>> --cacert "ca.pem" \
>> --header "Version: 3" \
>> --header "Content-Type: application/xml" \
>> --user "${user}:${password}" \
>> --request PUT \
>> --data "
>> 
>>   newalias
>> 
>> " \
>> "${url}/vms/${vm_id}/disks/${disk_id}"
>> --->8---
>>
>> >
>> > On Wed, Jun 28, 2017 at 10:07 AM, Daniel Erez <de...@redhat.com
>> > <mailto:de...@redhat.com>> wrote:
>> >
>> > Hi,
>> >
>> > Updating is done using the PUT method.
>> > Please try that with the same XML body.
>> >
>> > Thanks,
>> > Daniel
>> >
>> > On Wed, Jun 28, 2017 at 10:26 AM Bruno Rodriguez <br...@pic.es
>> > <mailto:br...@pic.es>> wrote:
>> >
>> > Hello everyone,
>> >
>> > I'm having some problems about renaming some disks (setting a
>> > different alias, name or description) for VMs disks created from
>> > a template. When I get this URL
>> >
>> > https://ovirt-manager/ovirt-engine/api/disks/0123
>> > <https://ovirt-manager/ovirt-engine/api/disks/0123>
>> >
>> > I can see are the methods sparsify, export, move and copy. I
>> > tried to POST the following XML to the previous URL with no
>> > result (as expected, it won't work)
>> >
>> > 
>> >   my_machine_Disk1
>> > 
>> >
>> > I'm quite sure I'm thinking about it in a wrong way (as usual).
>> > Any help would be welcome...
>> >
>> > Thank you in advance
>> >
>> > --
>> > Bruno Rodríguez Rodríguez
>> >
>> > *Port d'Informació Científica (PIC)*
>> >
>> > ___
>> > Users mailing list
>> > Users@ovirt.org <mailto:Users@ovirt.org>
>> > http://lists.ovirt.org/mailman/listinfo/users
>> > <http://lists.ovirt.org/mailman/listinfo/users>
>> >
>> >
>> >
>> >
>> > --
>> > Bruno Rodríguez Rodríguez
>> >
>> > *Port d'Informació Científica (PIC)*
>> > Campus UAB - Edificio D,
>> > C / Albareda, s / n
>> > 08193-Bellaterra (B

Re: [ovirt-users] Unable to rename disks via REST API

2017-06-28 Thread Bruno Rodriguez
Thank you very much !!!

I expected I was missing something like that. Thanks again!

On Wed, Jun 28, 2017 at 11:12 AM, Juan Hernández <jhern...@redhat.com>
wrote:

> On 06/28/2017 10:43 AM, Bruno Rodriguez wrote:
> > Thank you, Daniel
> >
> > I tried a PUT with the same XML body, I got a "405 Method Not Allowed".
> > It's quite strange, there must be someting I'm missing
> >
>
> The operation to update a disk will be introduced in version 4 of the
> API with version 4.2 of the engine. Meanwhile the way to update the disk
> is to use version 3 of the API and the disks sub-collection of the
> virtual machine. That means that if you have a VM with id 123 and a disk
> with id 456 you can send a request like this:
>
>   PUT /ovirt-engine/api/v3/vms/123/disks/456
>
> With a request body like this:
>
>   
> newalias
>   
>
> Note that you can use the above "v3" prefix in the URL or else the
> "Version: 3" header. A complete example using curl:
>
> ---8<---
> #!/bin/bash -ex
>
> url="https://.../ovirt-engine/api;
> user="admin@internal"
> password="..."
> vm_id="..."
> disk_id="..."
>
> curl \
> --verbose \
> --cacert "ca.pem" \
> --header "Version: 3" \
> --header "Content-Type: application/xml" \
> --user "${user}:${password}" \
> --request PUT \
> --data "
> 
>   newalias
> 
> " \
> "${url}/vms/${vm_id}/disks/${disk_id}"
> --->8---
>
> >
> > On Wed, Jun 28, 2017 at 10:07 AM, Daniel Erez <de...@redhat.com
> > <mailto:de...@redhat.com>> wrote:
> >
> > Hi,
> >
> > Updating is done using the PUT method.
> > Please try that with the same XML body.
> >
> > Thanks,
> > Daniel
> >
> > On Wed, Jun 28, 2017 at 10:26 AM Bruno Rodriguez <br...@pic.es
> > <mailto:br...@pic.es>> wrote:
> >
> > Hello everyone,
> >
> > I'm having some problems about renaming some disks (setting a
> > different alias, name or description) for VMs disks created from
> > a template. When I get this URL
> >
> > https://ovirt-manager/ovirt-engine/api/disks/0123
> > <https://ovirt-manager/ovirt-engine/api/disks/0123>
> >
> > I can see are the methods sparsify, export, move and copy. I
> > tried to POST the following XML to the previous URL with no
> > result (as expected, it won't work)
> >
> > 
> >   my_machine_Disk1
> > 
> >
> > I'm quite sure I'm thinking about it in a wrong way (as usual).
> > Any help would be welcome...
> >
> > Thank you in advance
> >
> > --
> > Bruno Rodríguez Rodríguez
> >
> > *Port d'Informació Científica (PIC)*
> >
> > ___
> > Users mailing list
> > Users@ovirt.org <mailto:Users@ovirt.org>
> > http://lists.ovirt.org/mailman/listinfo/users
> > <http://lists.ovirt.org/mailman/listinfo/users>
> >
> >
> >
> >
> > --
> > Bruno Rodríguez Rodríguez
> >
> > *Port d'Informació Científica (PIC)*
> > Campus UAB - Edificio D,
> > C / Albareda, s / n
> > 08193-Bellaterra (Barcelona), España
> > Telf. +34 93 170 27 30
> > GPS  coordenadas:  41.500850 2.110628
> >
> > "Si algo me ha enseñado el tetris, es que los errores se acumulan y los
> > triunfos desaparecen"
> >
> >
> > ___
> > Users mailing list
> > Users@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
>
>


-- 
Bruno Rodríguez Rodríguez

*Port d'Informació Científica (PIC)*
Campus UAB - Edificio D,
C / Albareda, s / n
08193-Bellaterra (Barcelona), España
Telf. +34 93 170 27 30
GPS  coordenadas:  41.500850 2.110628

"Si algo me ha enseñado el tetris, es que los errores se acumulan y los
triunfos desaparecen"
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Unable to rename disks via REST API

2017-06-28 Thread Bruno Rodriguez
Thank you, Daniel

I tried a PUT with the same XML body, I got a "405 Method Not Allowed".
It's quite strange, there must be someting I'm missing



On Wed, Jun 28, 2017 at 10:07 AM, Daniel Erez <de...@redhat.com> wrote:

> Hi,
>
> Updating is done using the PUT method.
> Please try that with the same XML body.
>
> Thanks,
> Daniel
>
> On Wed, Jun 28, 2017 at 10:26 AM Bruno Rodriguez <br...@pic.es> wrote:
>
>> Hello everyone,
>>
>> I'm having some problems about renaming some disks (setting a different
>> alias, name or description) for VMs disks created from a template. When I
>> get this URL
>>
>> https://ovirt-manager/ovirt-engine/api/disks/0123
>>
>> I can see are the methods sparsify, export, move and copy. I tried to
>> POST the following XML to the previous URL with no result (as expected, it
>> won't work)
>>
>> 
>>   my_machine_Disk1
>> 
>>
>> I'm quite sure I'm thinking about it in a wrong way (as usual). Any help
>> would be welcome...
>>
>> Thank you in advance
>>
>> --
>> Bruno Rodríguez Rodríguez
>>
>> *Port d'Informació Científica (PIC)*
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>


-- 
Bruno Rodríguez Rodríguez

*Port d'Informació Científica (PIC)*
Campus UAB - Edificio D,
C / Albareda, s / n
08193-Bellaterra (Barcelona), España
Telf. +34 93 170 27 30
GPS  coordenadas:  41.500850 2.110628

"Si algo me ha enseñado el tetris, es que los errores se acumulan y los
triunfos desaparecen"
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


[ovirt-users] Unable to rename disks via REST API

2017-06-28 Thread Bruno Rodriguez
Hello everyone,

I'm having some problems about renaming some disks (setting a different
alias, name or description) for VMs disks created from a template. When I
get this URL

https://ovirt-manager/ovirt-engine/api/disks/0123

I can see are the methods sparsify, export, move and copy. I tried to POST
the following XML to the previous URL with no result (as expected, it won't
work)


  my_machine_Disk1


I'm quite sure I'm thinking about it in a wrong way (as usual). Any help
would be welcome...

Thank you in advance

-- 
Bruno Rodríguez Rodríguez

*Port d'Informació Científica (PIC)*
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Problem while adding a VM NIC via REST API

2017-06-02 Thread Bruno Rodriguez
On Fri, Jun 2, 2017 at 4:09 PM, Juan Hernández <jhern...@redhat.com> wrote:

> On 06/02/2017 03:56 PM, Bruno Rodriguez wrote:
> > Hello everyone,
> >
> > I have some scripts that create VMs, which are in perl using libcurl and
> > oVirt REST API. They work quite fine but I'm experiencing something
> unusual.
> >
> > After I create the machine (let's suppose it's called server.pic.es
> > <http://server.pic.es>) with UUID 123abc I post the following REST API
> > call to https://... /vms/123abc/nics
> >
> > 
> > server.pic.es_nic1
> > virtio
> > VLANXXX
> > 
> >
> > The NIC is created and attached to the VM but it's network field is
> > empty, not in the VLANXXX. I don't know if I'm missing something but
> > this worked flawlessly with 3.6.9 REST API.
> >
> > Some people could say: "it's because you're using Perl". Yup, that's
> > probably a mental issue of mine and I should visit a doctor about using
> > it, but it doesn't work even using a fancy REST browser extension to
> > send requests (ARC for chromium), anyways the REST reply is a "201:
> > Created" that looks OK...
> >
> > Any idea or suggestion will be welcome. Thanks in advance!
> >
>
> It is not because of Perl :-) .
>
> In version 4 of the API it is mandatory to specify the NIC profile, as
> the network may have multiple profiles. So you need to find the
> identifier of that NIC profile and then send a request like this:
>
>   
> server.pic.es_nic1
> virtio
> 
>   
>
> You can find the identifiers of the profiles like this:
>
>   GET /ovirt-engine/api/networks/the_identifier_of_the_network/
> vnicprofildes
>
> If you want the old behavior, the behavior of version 3 of the API, you
> can just add to your request the 'Version: 3' HTTP header. But note that
> version 3 of the API is deprecated since version 4.0 of the engine, and
> it will be removed with version 4.2 of the engine.
>

Thank you very much, I'll probably have to check that and add an "if"
because I already was having problems with the APIv4 disks creation...

Thanks again!
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


[ovirt-users] Problem while adding a VM NIC via REST API

2017-06-02 Thread Bruno Rodriguez
Hello everyone,

I have some scripts that create VMs, which are in perl using libcurl and
oVirt REST API. They work quite fine but I'm experiencing something unusual.

After I create the machine (let's suppose it's called server.pic.es) with
UUID 123abc I post the following REST API call to https://...
/vms/123abc/nics


server.pic.es_nic1
virtio
VLANXXX


The NIC is created and attached to the VM but it's network field is empty,
not in the VLANXXX. I don't know if I'm missing something but this worked
flawlessly with 3.6.9 REST API.

Some people could say: "it's because you're using Perl". Yup, that's
probably a mental issue of mine and I should visit a doctor about using it,
but it doesn't work even using a fancy REST browser extension to send
requests (ARC for chromium), anyways the REST reply is a "201: Created"
that looks OK...

Any idea or suggestion will be welcome. Thanks in advance!

-- 
Bruno Rodríguez Rodríguez

*Port d'Informació Científica (PIC)*
Campus UAB - Edificio D,
C / Albareda, s / n
08193-Bellaterra (Barcelona), España
Telf. +34 93 170 27 30
GPS  coordenadas:  41.500850 2.110628

"Si algo me ha enseñado el tetris, es que los errores se acumulan y los
triunfos desaparecen"
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] Error authenticating bind using the AAA OpenLDAP module

2015-01-15 Thread Bruno Rodriguez
),

Bruno


On Thu, Jan 15, 2015 at 10:20 AM, Bruno Rodriguez br...@pic.es wrote:

 Thank you very much,

 using the following ldap.example.org file:

 -

 include = openldap_example.properties
 include = rfc2307.properties

 vars.server = ldap1.example.org
 #vars.user = cn=authenticate,ou=System,dc=example,dc=org
 #vars.password = X

 pool.default.serverset.single.server = ${global:vars.server}
 pool.default.auth.simple.bindDN =
 cn=authenticate,ou=System,dc=example,dc=org
 pool.default.auth.simple.password = X

 pool.default.ssl.startTLS = true
 pool.default.ssl.truststore.file =
 /etc/ovirt-engine/extensions.d/ldap.example.org_keystore.jks
 pool.default.ssl.truststore.password = X

 -

 Then I get the following in the engine log:


 2015-01-15 10:04:15,250 ERROR
 [org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand]
 (ajp--127.0.0.1-8702-3) Error during CanDoActionFailure.: Class: class
 org.ovirt.engine.core.extensions.mgr.ExtensionInvokeCommandFailedException
 Input:
 {Extkey[name=AAA_AUTHN_CREDENTIALS;type=class
 java.lang.String;uuid=AAA_AUTHN_CREDENTIALS[03b96485-4bb5-4592-8167-810a5c909706];]=***,
 Extkey[name=EXTENSION_INVOKE_CONTEXT;type=class
 org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_INVOKE_CONTEXT[886d2ebb-312a-49ae-9cc3-e1f849834b7d];]={Extkey[name=EXTENSION_INTERFACE_VERSION_MAX;type=class
 java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_MAX[f4cff49f-2717-4901-8ee9-df362446e3e7];]=0,
 Extkey[name=EXTENSION_LICENSE;type=class
 java.lang.String;uuid=EXTENSION_LICENSE[8a61ad65-054c-4e31-9c6d-1ca4d60a4c18];]=ASL
 2.0, Extkey[name=EXTENSION_NOTES;type=class
 java.lang.String;uuid=EXTENSION_NOTES[2da5ad7e-185a-4584-aaff-97f66978e4ea];]=Display
 name: ovirt-engine-extension-aaa-ldap-1.0.0-1.el6,
 Extkey[name=EXTENSION_HOME_URL;type=class
 java.lang.String;uuid=EXTENSION_HOME_URL[4ad7a2f4-f969-42d4-b399-72d192e18304];]=
 http://www.ovirt.org,Extkey[name=EXTENSION_LOCALE;type=class
 java.lang.String;uuid=EXTENSION_LOCALE[0780b112-0ce0-404a-b85e-8765d778bb29];]=en_US,
 Extkey[name=EXTENSION_NAME;type=class
 java.lang.String;uuid=EXTENSION_NAME[651381d3-f54f-4547-bf28-b0b01a103184];]=ovirt-engine-extension-aaa-ldap.authn,
 Extkey[name=EXTENSION_INTERFACE_VERSION_MIN;type=class
 java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_MIN[2b84fc91-305b-497b-a1d7-d961b9d2ce0b];]=0,
 Extkey[name=EXTENSION_CONFIGURATION;type=class
 java.util.Properties;uuid=EXTENSION_CONFIGURATION[2d48ab72-f0a1-4312-b4ae-5068a226b0fc];]=***,
 Extkey[name=EXTENSION_AUTHOR;type=class
 java.lang.String;uuid=EXTENSION_AUTHOR[ef242f7a-2dad-4bc5-9aad-e07018b7fbcc];]=The
 oVirt Project, Extkey[name=EXTENSION_INSTANCE_NAME;type=class
 java.lang.String;uuid=EXTENSION_INSTANCE_NAME[65c67ff6-aeca-4bd5-a245-8674327f011b];]=
 authn-ldap.example.org,
 Extkey[name=EXTENSION_BUILD_INTERFACE_VERSION;type=class
 java.lang.Integer;uuid=EXTENSION_BUILD_INTERFACE_VERSION[cb479e5a-4b23-46f8-aed3-56a4747a8ab7];]=0,
 Extkey[name=EXTENSION_CONFIGURATION_SENSITIVE_KEYS;type=interface
 java.util.Collection;uuid=EXTENSION_CONFIGURATION_SENSITIVE_KEYS[a456efa1-73ff-4204-9f9b-ebff01e35263];]=[],
 Extkey[name=AAA_AUTHN_CAPABILITIES;type=class
 java.lang.Long;uuid=AAA_AUTHN_CAPABILITIES[9d16bee3-10fd-46f2-83f9-3d3c54cf258d];]=12,
 Extkey[name=EXTENSION_GLOBAL_CONTEXT;type=class
 org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_GLOBAL_CONTEXT[9799e72f-7af6-4cf1-bf08-297bc8903676];]=*skip*,
 Extkey[name=EXTENSION_VERSION;type=class
 java.lang.String;uuid=EXTENSION_VERSION[fe35f6a8-8239-4bdb-ab1a-af9f779ce68c];]=1.0.0,
 Extkey[name=EXTENSION_MANAGER_TRACE_LOG;type=interface
 org.slf4j.Logger;uuid=EXTENSION_MANAGER_TRACE_LOG[863db666-3ea7-4751-9695-918a3197ad83];]=org.slf4j.impl.Slf4jLogger(
 org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace.ovirt-engine-extension-aaa-ldap.authn.authn-ldap.example.org),
 Extkey[name=EXTENSION_PROVIDES;type=interface
 java.util.Collection;uuid=EXTENSION_PROVIDES[8cf373a6-65b5-4594-b828-0e275087de91];]=[org.ovirt.engine.api.extensions.aaa.Authn]},
 Extkey[name=AAA_AUTHN_USER;type=class
 java.lang.String;uuid=AAA_AUTHN_USER[1ceaba26-1bdc-4663-a3c6-5d926f9dd8f0];]=bruno,
 Extkey[name=EXTENSION_INVOKE_COMMAND;type=class
 org.ovirt.engine.api.extensions.ExtUUID;uuid=EXTENSION_INVOKE_COMMAND[485778ab-bede-4f1a-b823-77b262a2f28d];]=AAA_AUTHN_AUTHENTICATE_CREDENTIALS[d9605c75-6b43-4b00-b32c-06bdfa80244c]}
  Output:
  {Extkey[name=EXTENSION_INVOKE_RESULT;type=class
 java.lang.Integer;uuid=EXTENSION_INVOKE_RESULT[0909d91d-8bde-40fb-b6c0-099c772ddd4e];]=2,
 Extkey[name=EXTENSION_INVOKE_MESSAGE;type=class
 java.lang.String;uuid=EXTENSION_INVOKE_MESSAGE[b7b053de-dc73-4bf7-9d26-b8bdb72f5893];]=anonymous
 bind disallowed}

 ---

 And this is the ldap connection log:

 /var/log/ldap.log:Jan 15 10:04:15 ldap1 slapd[6712]: conn=1671350 fd=114
 ACCEPT from IP=192.168.XX.XX:41469 (IP=0.0.0.0:389)
 /var/log/ldap.log:Jan 15 10:04:15

Re: [ovirt-users] Error authenticating bind using the AAA OpenLDAP module

2015-01-15 Thread Bruno Rodriguez
Thanks ! Now it's working!

The problem was the absence of the line:

pool.default.auth.type = simple

It's strange, I thought that the default auth type was set to simple and I
didn't check it twice. After setting that the problem has to do about a
user/password incorrect, which is our problem because of the schema we are
using (migrated from a NIS some time ago).

The openldap_example.properties actually was a copy of openldap.properties,
I did it that way to customize it to our  schema, but in a first instance
it was a carbon copy of the original.

Thanks again !

Bruno



On Thu, Jan 15, 2015 at 10:43 AM, Ondra Machacek omach...@redhat.com
wrote:

 On 01/15/2015 10:36 AM, Alon Bar-Lev wrote:



 - Original Message -

 From: Bruno Rodriguez br...@pic.es
 To: Ondra Machacek omach...@redhat.com
 Cc: Esther Accion esth...@pic.es, users@ovirt.org
 Sent: Thursday, January 15, 2015 11:20:57 AM
 Subject: Re: [ovirt-users] Error authenticating bind using the AAA
 OpenLDAP module

 Thank you very much,

 using the following ldap.example.org file:

 -

 include = openldap_example.properties
 include = rfc2307.properties


 what do you have in openldap_example.properties?


 It seems you have specified anonymous bind in openldap_example.properties.
 You should probably try it with original one (openldap.properties).



  vars.server = ldap1.example.org
 #vars.user = cn=authenticate,ou=System,dc=example,dc=org
 #vars.password = X


 why have you commented out the vars?
 you should have just removed the quotes from vars.password and keep
 bellow as-is.

  pool.default.serverset.single.server = ${global:vars.server}
 pool.default.auth.simple.bindDN = cn=authenticate,ou=System,dc=
 example,dc=org
 pool.default.auth.simple.password = X

 pool.default.ssl.startTLS = true
 pool.default.ssl.truststore.file =
 /etc/ovirt-engine/extensions.d/ldap.example.org_keystore.jks
 pool.default.ssl.truststore.password = X

 -

 Then I get the following in the engine log:


 2015-01-15 10:04:15,250 ERROR
 [org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand]
 (ajp--127.0.0.1-8702-3) Error during CanDoActionFailure.: Class: class
 org.ovirt.engine.core.extensions.mgr.ExtensionInvokeCommandFailedEx
 ception
 Input:
 {Extkey[name=AAA_AUTHN_CREDENTIALS;type=class
 java.lang.String;uuid=AAA_AUTHN_CREDENTIALS[03b96485-
 4bb5-4592-8167-810a5c909706];]=***,
 Extkey[name=EXTENSION_INVOKE_CONTEXT;type=class
 org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_INVOKE_CONTEXT[
 886d2ebb-312a-49ae-9cc3-e1f849834b7d];]={Extkey[name=
 EXTENSION_INTERFACE_VERSION_MAX;type=class
 java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_
 MAX[f4cff49f-2717-4901-8ee9-df362446e3e7];]=0,
 Extkey[name=EXTENSION_LICENSE;type=class
 java.lang.String;uuid=EXTENSION_LICENSE[8a61ad65-
 054c-4e31-9c6d-1ca4d60a4c18];]=ASL
 2.0, Extkey[name=EXTENSION_NOTES;type=class
 java.lang.String;uuid=EXTENSION_NOTES[2da5ad7e-185a-
 4584-aaff-97f66978e4ea];]=Display
 name: ovirt-engine-extension-aaa-ldap-1.0.0-1.el6,
 Extkey[name=EXTENSION_HOME_URL;type=class
 java.lang.String;uuid=EXTENSION_HOME_URL[4ad7a2f4-
 f969-42d4-b399-72d192e18304];]=
 http://www.ovirt.org ,Extkey[name=EXTENSION_LOCALE;type=class
 java.lang.String;uuid=EXTENSION_LOCALE[0780b112-
 0ce0-404a-b85e-8765d778bb29];]=en_US,
 Extkey[name=EXTENSION_NAME;type=class
 java.lang.String;uuid=EXTENSION_NAME[651381d3-f54f-
 4547-bf28-b0b01a103184];]=ovirt-engine-extension-aaa-ldap.authn,
 Extkey[name=EXTENSION_INTERFACE_VERSION_MIN;type=class
 java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_
 MIN[2b84fc91-305b-497b-a1d7-d961b9d2ce0b];]=0,
 Extkey[name=EXTENSION_CONFIGURATION;type=class
 java.util.Properties;uuid=EXTENSION_CONFIGURATION[
 2d48ab72-f0a1-4312-b4ae-5068a226b0fc];]=***,
 Extkey[name=EXTENSION_AUTHOR;type=class
 java.lang.String;uuid=EXTENSION_AUTHOR[ef242f7a-
 2dad-4bc5-9aad-e07018b7fbcc];]=The
 oVirt Project, Extkey[name=EXTENSION_INSTANCE_NAME;type=class
 java.lang.String;uuid=EXTENSION_INSTANCE_NAME[65c67ff6-aeca-4bd5-a245-
 8674327f011b];]=
 authn-ldap.example.org ,
 Extkey[name=EXTENSION_BUILD_INTERFACE_VERSION;type=class
 java.lang.Integer;uuid=EXTENSION_BUILD_INTERFACE_
 VERSION[cb479e5a-4b23-46f8-aed3-56a4747a8ab7];]=0,
 Extkey[name=EXTENSION_CONFIGURATION_SENSITIVE_KEYS;type=interface
 java.util.Collection;uuid=EXTENSION_CONFIGURATION_
 SENSITIVE_KEYS[a456efa1-73ff-4204-9f9b-ebff01e35263];]=[],
 Extkey[name=AAA_AUTHN_CAPABILITIES;type=class
 java.lang.Long;uuid=AAA_AUTHN_CAPABILITIES[9d16bee3-10fd-
 46f2-83f9-3d3c54cf258d];]=12,
 Extkey[name=EXTENSION_GLOBAL_CONTEXT;type=class
 org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_GLOBAL_CONTEXT[
 9799e72f-7af6-4cf1-bf08-297bc8903676];]=*skip*,
 Extkey[name=EXTENSION_VERSION;type=class
 java.lang.String;uuid=EXTENSION_VERSION[fe35f6a8-
 8239-4bdb-ab1a-af9f779ce68c];]=1.0.0,
 Extkey[name=EXTENSION_MANAGER_TRACE_LOG;type=interface
 org.slf4j.Logger;uuid

Re: [ovirt-users] Error authenticating bind using the AAA OpenLDAP module

2015-01-15 Thread Bruno Rodriguez
/log/ldap.log:Jan 15 10:04:15 ldap1 slapd[6712]: conn=1671350 op=0
RESULT oid= err=0 text=
/var/log/ldap.log:Jan 15 10:04:15 ldap1 slapd[6712]: conn=1671350 fd=114
TLS established tls_ssf=128 ssf=128
/var/log/ldap.log:Jan 15 10:04:15 ldap1 slapd[6712]: conn=1671350 op=1 BIND
dn=cn=authenticate,ou=System,dc=example,dc=org method=128
/var/log/ldap.log:Jan 15 10:04:15 ldap1 slapd[6712]: conn=1671350 op=1 BIND
dn=cn=authenticate,ou=System,dc=example,dc=org mech=SIMPLE ssf=0
/var/log/ldap.log:Jan 15 10:04:15 ldap1 slapd[6712]: conn=1671350 op=1
RESULT tag=97 err=0 text=

---

It looks like it got the dn correctly but it's unable to bind anyway ...

Thank you,

Bruno


On Wed, Jan 14, 2015 at 5:50 PM, Ondra Machacek omach...@redhat.com wrote:

 Hi,

 On 01/14/2015 04:53 PM, Bruno Rodriguez wrote:

 Good afternoon,

 We cannot access to Ovirt using LDAP authentication against our openldap
 server. We created the following files in /etc/ovirt-engine/extensions.d
 (the organization name is not example.org http://example.org and the
 passwords are not , obviously) :

 --- /etc/ovirt-engine/extensions.d/ldap.example.org
 http://ldap.example.org ---

 include = openldap_example.properties

 vars.server = ldap1.example.org http://ldap1.example.org
 vars.user = cn=authenticate,ou=System,dc=example,dc=org
 vars.password = 

 pool.default.serverset.single.server = ${global:vars.server}
 pool.default.auth.simple.bindDN = ${global:vars.user}
 pool.default.auth.simple.password = ${global:vars.password}

 pool.default.ssl.startTLS = true
 pool.default.ssl.truststore.file =
 /etc/ovirt-engine/extensions.d/ldap.example.org_keystore.jks
 pool.default.ssl.truststore.password = 

 ---
 /etc/ovirt-engine/extensions.d/authn-ldap.example.org.properties
 ---

 ovirt.engine.extension.name http://ovirt.engine.extension.name =
 authn-ldap.example.org http://authn-ldap.example.org
 ovirt.engine.extension.bindings.method = jbossmodule
 ovirt.engine.extension.binding.jbossmodule.module =
 org.ovirt.engine-extensions.aaa.ldap
 ovirt.engine.extension.binding.jbossmodule.class =
 org.ovirt.engineextensions.aaa.ldap.AuthnExtension
 ovirt.engine.extension.provides = org.ovirt.engine.api.
 extensions.aaa.Authn

 ovirt.engine.aaa.authn.profile.name
 http://ovirt.engine.aaa.authn.profile.name = ldap.example.org
 http://ldap.example.org
 ovirt.engine.aaa.authn.authz.plugin = authz-ldap.example.org
 http://authz-ldap.example.org

 config.profile.file.1 = /etc/ovirt-engine/extensions.d/ldap.example.org
 http://ldap.example.org

 ---
 /etc/ovirt-engine/extensions.d/authz-ldap.example.org.properties
 ---

 ovirt.engine.extension.name http://ovirt.engine.extension.name =
 authz-ldap.example.org http://authz-ldap.example.org
 ovirt.engine.extension.bindings.method = jbossmodule
 ovirt.engine.extension.binding.jbossmodule.module =
 org.ovirt.engine-extensions.aaa.ldap
 ovirt.engine.extension.binding.jbossmodule.class =
 org.ovirt.engineextensions.aaa.ldap.AuthzExtension

 ovirt.engine.extension.provides = org.ovirt.engine.api.
 extensions.aaa.Authz
 config.profile.file.1 = /etc/ovirt-engine/extensions.d/ldap.example.org
 http://ldap.example.org

 

 After all of this we restarted the service and tried to access via the
 administration portal. The JKS has the right permissions and contains
 the TLS CA, the password is correct and the user esthera exists. But
 when we try to log in, we obtain the following error in the engine.log
 (we already set the verbosity to ALL):

 

 2015-01-14 16:35:25,750 ERROR
 [org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand]
 (ajp--127.0.0.1-8702-6) Error during CanDoActionFailure.: Class: class
 org.ovirt.engine.core.extensions.mgr.ExtensionInvokeCommandFailedEx
 ception
 Input:
 {Extkey[name=AAA_AUTHN_CREDENTIALS;type=class
 java.lang.String;uuid=AAA_AUTHN_CREDENTIALS[03b96485-
 4bb5-4592-8167-810a5c909706];]=***,
 Extkey[name=EXTENSION_INVOKE_CONTEXT;type=class
 org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_INVOKE_CONTEXT[
 886d2ebb-312a-49ae-9cc3-e1f849834b7d];]={Extkey[name=
 EXTENSION_INTERFACE_VERSION_MAX;type=class
 java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_
 MAX[f4cff49f-2717-4901-8ee9-df362446e3e7];]=0,
 Extkey[name=EXTENSION_LICENSE;type=class
 java.lang.String;uuid=EXTENSION_LICENSE[8a61ad65-
 054c-4e31-9c6d-1ca4d60a4c18];]=ASL
 2.0, Extkey[name=EXTENSION_NOTES;type=class
 java.lang.String;uuid=EXTENSION_NOTES[2da5ad7e-185a-
 4584-aaff-97f66978e4ea];]=Display
 name: ovirt-engine-extension-aaa-ldap-1.0.0-1.el6,
 Extkey[name=EXTENSION_HOME_URL;type=class
 java.lang.String;uuid=EXTENSION_HOME_URL[4ad7a2f4-
 f969-42d4-b399-72d192e18304];]=http://www.ovirt.org
 http://www.ovirt.org/, Extkey[name=EXTENSION_LOCALE;type=class
 java.lang.String;uuid=EXTENSION_LOCALE[0780b112-
 0ce0-404a-b85e-8765d778bb29];]=en_US

[ovirt-users] Error authenticating bind using the AAA OpenLDAP module

2015-01-14 Thread Bruno Rodriguez
Good afternoon,

We cannot access to Ovirt using LDAP authentication against our openldap
server. We created the following files in /etc/ovirt-engine/extensions.d
(the organization name is not example.org and the passwords are not
, obviously) :

--- /etc/ovirt-engine/extensions.d/ldap.example.org ---

include = openldap_example.properties

vars.server = ldap1.example.org
vars.user = cn=authenticate,ou=System,dc=example,dc=org
vars.password = 

pool.default.serverset.single.server = ${global:vars.server}
pool.default.auth.simple.bindDN = ${global:vars.user}
pool.default.auth.simple.password = ${global:vars.password}

pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file =
/etc/ovirt-engine/extensions.d/ldap.example.org_keystore.jks
pool.default.ssl.truststore.password = 

---
/etc/ovirt-engine/extensions.d/authn-ldap.example.org.properties ---

ovirt.engine.extension.name = authn-ldap.example.org
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module =
org.ovirt.engine-extensions.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class =
org.ovirt.engineextensions.aaa.ldap.AuthnExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn

ovirt.engine.aaa.authn.profile.name = ldap.example.org
ovirt.engine.aaa.authn.authz.plugin = authz-ldap.example.org

config.profile.file.1 = /etc/ovirt-engine/extensions.d/ldap.example.org

---
/etc/ovirt-engine/extensions.d/authz-ldap.example.org.properties ---

ovirt.engine.extension.name = authz-ldap.example.org
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module =
org.ovirt.engine-extensions.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class =
org.ovirt.engineextensions.aaa.ldap.AuthzExtension

ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
config.profile.file.1 = /etc/ovirt-engine/extensions.d/ldap.example.org



After all of this we restarted the service and tried to access via the
administration portal. The JKS has the right permissions and contains the
TLS CA, the password is correct and the user esthera exists. But when we
try to log in, we obtain the following error in the engine.log (we already
set the verbosity to ALL):



2015-01-14 16:35:25,750 ERROR
[org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand]
(ajp--127.0.0.1-8702-6) Error during CanDoActionFailure.: Class: class
org.ovirt.engine.core.extensions.mgr.ExtensionInvokeCommandFailedException
Input:
{Extkey[name=AAA_AUTHN_CREDENTIALS;type=class java.lang.String;uuid=AAA_
AUTHN_CREDENTIALS[03b96485-4bb5-4592-8167-810a5c909706];]=***,
Extkey[name=EXTENSION_INVOKE_CONTEXT;type=class org.ovirt.engine.api.
extensions.ExtMap;uuid=EXTENSION_INVOKE_CONTEXT[886d2ebb-312a-49ae-9cc3-
e1f849834b7d];]={Extkey[name=EXTENSION_INTERFACE_VERSION_MAX;type=class
java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_
MAX[f4cff49f-2717-4901-8ee9-df362446e3e7];]=0,
Extkey[name=EXTENSION_LICENSE;type=class java.lang.String;uuid=
EXTENSION_LICENSE[8a61ad65-054c-4e31-9c6d-1ca4d60a4c18];]=ASL 2.0,
Extkey[name=EXTENSION_NOTES;type=class java.lang.String;uuid=
EXTENSION_NOTES[2da5ad7e-185a-4584-aaff-97f66978e4ea];]=Display name:
ovirt-engine-extension-aaa-ldap-1.0.0-1.el6,
Extkey[name=EXTENSION_HOME_URL;type=class
java.lang.String;uuid=EXTENSION_HOME_URL[4ad7a2f4-
f969-42d4-b399-72d192e18304];]=http://www.ovirt.org,
Extkey[name=EXTENSION_LOCALE;type=class java.lang.String;uuid=
EXTENSION_LOCALE[0780b112-0ce0-404a-b85e-8765d778bb29];]=en_US,
Extkey[name=EXTENSION_NAME;type=class java.lang.String;uuid=
EXTENSION_NAME[651381d3-f54f-4547-bf28-b0b01a103184];]=
ovirt-engine-extension-aaa-ldap.authn, Extkey[name=EXTENSION_
INTERFACE_VERSION_MIN;type=class java.lang.Integer;uuid=
EXTENSION_INTERFACE_VERSION_MIN[2b84fc91-305b-497b-a1d7-d961b9d2ce0b];]=0,
Extkey[name=EXTENSION_CONFIGURATION;type=class java.util.Properties;uuid=
EXTENSION_CONFIGURATION[2d48ab72-f0a1-4312-b4ae-5068a226b0fc];]=***,
Extkey[name=EXTENSION_AUTHOR;type=class java.lang.String;uuid=
EXTENSION_AUTHOR[ef242f7a-2dad-4bc5-9aad-e07018b7fbcc];]=The oVirt Project,
Extkey[name=EXTENSION_INSTANCE_NAME;type=class java.lang.String;uuid=
EXTENSION_INSTANCE_NAME[65c67ff6-aeca-4bd5-a245-8674327f011b];]=authn-ldap.
http://authn-ldap.pic.es/example.org,
Extkey[name=EXTENSION_BUILD_INTERFACE_VERSION;type=class
java.lang.Integer;uuid=EXTENSION_BUILD_INTERFACE_VERSION[cb479e5a-4b23-46f8-aed3-56a4747a8ab7];]=0,
Extkey[name=EXTENSION_CONFIGURATION_SENSITIVE_KEYS;type=interface
java.util.Collection;uuid=EXTENSION_CONFIGURATION_
SENSITIVE_KEYS[a456efa1-73ff-4204-9f9b-ebff01e35263];]=[],
Extkey[name=AAA_AUTHN_CAPABILITIES;type=class java.lang.Long;uuid=AAA_AUTHN_
CAPABILITIES[9d16bee3-10fd-46f2-83f9-3d3c54cf258d];]=12,