Re: [Unity-idm-discuss] Attribute Statements

[Björn H. <b.h...@fz...>]

Hi Krzysztof,

based on the examples in the documentation, I found a much simpler way
of defining attributes for my particular use case. My condition within
the parent group attribute statements is now the group membership.

groups contains '/parent/servers'
groups contains '/parent/users'

However, I do think that Unity should be able to work with arbitrary
values from sub-groups. I may not have quite grasped the difference
between eattr and eattrs, however using either one does not make a
difference for me.

Is it possible that urn:unicore:attrType:role is treated specially.
Using a similar statement for urn:unicore:attrType:xlogin only uses the
value on the particular entity.

Are enumerations somehow special when it comes to dynamic attributes?


Cheers,
Björn

Am 13.09.2016 um 11:34 schrieb Björn Hagemeier:
> Hi Krzysztof,
> 
> on quick remark. The dump I just sent you may not have contained the
> second rule to copy attributes from the server group. I did this for
> testing purposes, but it shows the problem as well, as the user role
> gets assigned to all entities in the parent group.
> 
> I had done the change for testing purposes, but it didn't lead to any
> resolution on my side.
> 
> 
> Cheers,
> Björn
> 
> Am 13.09.2016 um 11:31 schrieb Björn Hagemeier:
>> Hi Krzysztof,
>>
>> Am 13.09.2016 um 10:04 schrieb Krzysztof Benedyczak:
>>> Hi Björn,
>>>
>>> W dniu 13.09.2016 o 09:46, Björn Hagemeier pisze:
>>>> Hi there,
>>>>
>>>> I ran into a problem using attributes statements in Unity 1.9.3. I would
>>>> like to use an attribute statement to copy an attribute from sub-groups.
>>>> Entity membership within sub-groups is mutually exclusive, the attribute
>>>> in question gets assigned automatically based on group membership. When
>>>> using two attribute statements to copy the attribute from the respective
>>>> sub-groups, the attribute value is updated on all entities within the
>>>> parent group.
>>>>
>>>> parent: dynamic attribute value from sub-groups assigned to all entities
>>>> |- servers: all entities assigned role server
>>>> |- users: all entities assigned role user
>>>>
>>>> The dynamic attribute values are taken from one group or the other,
>>>> depending on the order of the statements and the conflict resolution.
>>>> Only 'overwrite previous' and 'skip' really work here, but again, due to
>>>> the entities and hence the attributes being mutually exclusive within
>>>> the sub-groups, there should not be any conflict (to the best of my
>>>> knowledge).
>>>>
>>>> Am I doing anything wrong or is the value selection and assignment not
>>>> sufficiently restrictive?
>>>
>>> Well, I'm not sure if I can extract the problem that you get from your 
>>> description. I understand that you have entities which are either in 
>>> parent/servers or parent/users (never both), and want to copy the same 
>>> attribute from a subgroup to have it also in the parent group. Is this 
>>> correct?
>> Absoultely
>>> If yes - what misbehavior do you get?
>> The attribute in question is set to the same value for ALL entities in
>> the parent group.
>>>
>>> And please provide details of the attribute statement that you use to 
>>> copy the attribute in question.
>> In order to copy the attribute from sub-group servers
>>
>> Extra group with attributes: /unicorex/servers
>> Condition: eattrs contains 'urn:unicore:attrType:role'
>> Dynamic attribute name: urn:unicore:attrType:role
>> Dynamic attribute values expression: eattrs['urn:unicore:attrType:role']
>> Dynamic attribute visibility: unlimited
>> Conflict resolution: skip
>>
>> And for sub-group users:
>>
>> Extra group with attributes: /unicorex/users
>> Condition: eattrs contains 'urn:unicore:attrType:role'
>> Dynamic attribute name: urn:unicore:attrType:role
>> Dynamic attribute values expression: eattrs['urn:unicore:attrType:role']
>> Dynamic attribute visibility: unlimited
>> Conflict resolution: skip
>>
>> The list entry (toString()-rendering?) of this statement not mention the
>> extra group, such that they look alike at first sight. But this is
>> probably just a UI issue.
>>
>> With conflict resolution 'skip', the first statement in the list wins,
>> with conflict resolution 'overwrite previous', then last one wins. This
>> is expected behaviour, but values are applied to all entities in the
>> parent group. I've attached what I think is a minimal example of this
>> problem. It's a database dump from a fresh Unity installation with all
>> example data removed. Maybe it helps in debugging the problem.
>>
>>
>> Best regards and thanks for your great support,
>> Björn
>>
>>>
>>> Cheers,
>>> Krzysztof
>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Unity-idm-discuss mailing list
>> Uni...@li...
>> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss
>>
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Unity-idm-discuss mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss
> 


-- 
Dipl.-Inform. Björn Hagemeier
Federated Systems and Data
Juelich Supercomputing Centre
Institute for Advanced Simulation

Phone: +49 2461 61 1584
Fax  : +49 2461 61 6656
Email: b.h...@fz...
Skype: bhagemeier
WWW  : http://www.fz-juelich.de/jsc

JSC is the coordinator of the
John von Neumann Institute for Computing
and member of the
Gauss Centre for Supercomputing

-------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------