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.
