On 04/22/2013 03:42 PM, Simo Sorce wrote:
> On Mon, 2013-04-22 at 08:48 -0400, Dmitri Pal wrote:
>> On 04/22/2013 07:34 AM, Martin Kosek wrote:
>>> On 04/21/2013 09:14 PM, Dmitri Pal wrote:
>>>> Hello,
>>>>
>>>> Please review the design page for the following ticket:
>>>> https://fedorahosted.org/freeipa/ticket/3583
>>>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems
>>>>
>>> Hello Dmitri,
>>>
>>> The design looks fine, I would just like to discuss the schema enhancements.
>>>
>>> I'd propose to not create our own artificial attributes, but rather use a
>>> standard existing userClass attributeType defined in RFC 4524 which is 
>>> already
>>> present in 389-ds schemas and which semantics seems to match what we want:
>>>
>>> ...
>>> 2.25.  userClass
>>>
>>>    The 'userClass' attribute specifies categories of computer or
>>>    application user.  The semantics placed on this attribute are for
>>>    local interpretation.  Examples of current usage of this attribute in
>>>    academia are "student", "staff", and "faculty".  Note that the
>>>    'organizationalStatus' attribute type is now often preferred, as it
>>>    makes no distinction between persons as opposed to users.
>>>
>>>       ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
>>>         EQUALITY caseIgnoreMatch
>>>         SUBSTR caseIgnoreSubstringsMatch
>>>         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
>>
>> I tried to find something like this but I did not see this attribute as
>> a part of the object classes used for user accounts ("person" and
>> derivatives).
>> This would perfectly match the need and would not require a creation of
>> the new attribute.
>> Ack!
>>
>>>
>>>    The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
>>>    'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
>>>    in [RFC4517].
>>
>> This is fine to. And it is MV which is good.
>>
>>> ...
>>>
>>> What about simply adding this attributeType as a MAY attribute for ipaHost
>>> objectClass?
>>
>>
>> I was thinking about this too but then we would have it in a bit
>> asymmetric way.
>> I am fine with that too.
>>
>>>
>>> As for user objects, what about adding new auxiliary objectClass called 
>>> ipaUser
>>> storing miscellaneous attributes like this one?
>>
>> This is fine except this is much more intrusive.
>> I was looking for a very simple, low cost fix that can be added with
>> very limited impact.
>> While creation of the ipaUser is probably the correct step it sounds a
>> bit bigger than I want it to be for now.
>>
>>>
>>> Or is there a benefit of having a specialized objectClass holding just this 
>>> one
>>> MAY attribute?
>>
>>
>> No.
>>
>> So here is what I suggest:
>> Split the ticket into two steps (tickets):
>> Step 1: add the userClass attribute to ipaHost - do it now. That should
>> be a very low impact change.
>> Step 2: sort out the right class hierarchy for user - this is a
>> candidate for next round of refactoring.
>>
>> Step 1 is the only requirement at the moment so let us go just for it.
> 
> +1, go for it!
> 
> Simo.
> 

Cool! I did the ticket work:
Step 1: https://fedorahosted.org/freeipa/ticket/3583
Step 2: https://fedorahosted.org/freeipa/ticket/3588

Martin

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to