>>> Howard Chu <[email protected]> schrieb am 14.03.2014 um 11:55 in Nachricht <[email protected]>: > Ulrich Windl wrote: >>>>> Howard Chu <[email protected]> schrieb am 14.03.2014 um 10:36 in Nachricht >> <[email protected]>: >>> Ulrich Windl wrote: >>>> Hi! >>>> >>>> I have a question on "entryUUID": Most (comonly used) group-like >>>> structures >>> use DNs for members. Are there any examples how to use entryUUID for >>> group-like structures? >>> >>> There are no standard schema that do this. I'd note that your question and >>> Alejandro's recommendation are contrary to the design of LDAP (and the X.500 >>> data model) - LDAP is meant to be a read-optimized hierarchical data store. >>> If >>> you simply use entryUUIDs for all references then you might as well use a >>> flat or relational database instead of a hierarchical one. >> >> Up to here I see no difference. > > Then you don't understand the difference between hierarchical namespaces and > > flat namespaces. I suppose you're not using any Unix filesystems very much > either.
It seems you know. Isn't it that openLDAP stores every entry in a linear database, assigning an entry number to each entry and then use an index to convert an arbitrary attribute like DN to an entry number? I fail to see the difference in a non-partitioned tree between hierarchical and flat here. > >>> In particular, listing memberships by DN gives you immediate knowledge of an >>> entry's location in the hierarchy, and clients can use DN's for direct >>> access to any entry of interest. Using entryUUID requires you to do a > search, >>> instead of a direct lookup. >> >> I agree here. >> >>> >>> There's of course a maintenance cost for using DNs as references - when DNs >>> are changed, you might also need to change every entry that references them, >>> which makes updates more expensive. But again, that's part of the LDAP >>> design: >>> writes can be more expensive, because reads must be as fast as possible. >> >> I tend to disagree: I think the DIT designers mixed up names and IDs right > from the beginning. I guess that's why every entry has a DN, and not a DID > (Distinquished ID). To me it seems that did not foresee that a DN might > change. Maybe it was due to UUIDs not being used at that time. Today you can > learn for the web trackers how to manage IDs correctly ;-) >> >> Maybe they new the DIT schema would be less attractive if you had > "non-speaking" DIDs instead of DNs rich of semantics. But that virtual > attractiveness seems to be a major problem: What happens if "dn: cn=Jane > Smith, ou=people, o=example.org" gets married or divorced? > > Your entire question is negated by the fact that X.500 provided a ModifyDN > operation from the very beginning. The point you're failing to realize is > that > nobody said that "cn" must be the distinguished naming attribute of an > entry. I did not say the problem is that a DN cannot be changed; I said the problem is that the DN changes if you follow the typical LDAP recommandations how to name your entries. >> >>> >>> This is also a distinguishing characteristic of M$ AD that differentiates it >>> from true LDAP implementations - in AD, references are stored internally as >>> GUIDs, and the GUID must be mapped to a name on every read operation. Thus >>> they avoid the expense of referential integrity updates when DNs change, but >>> as a consequence, read operations in AD are slower than writes. It's not a >>> tradeoff that makes sense for most LDAP uses, but M$ AD is not a shining >>> example of good design anyway. >> >> "ease of use, not ease of implementation" they say. > > Nonsense. Read optimization vs write optimization. AD chose to favor writes > over reads, LDAP/X.500 is intended to favor reads over writes. M$ AD chose > the > wrong option. >> >> (It's all my opinion) >> >> Regards, >> Ulrich >> >>> >>>> >>>> Regards, >>>> Ulrich >>>> >>>>>>> Alejandro Imass <[email protected]> schrieb am 13.03.2014 um 20:10 in >>>> Nachricht >>>> <CAHieY7TFQne1gyGe9-fWH3oYzZy-oBOQSha=klkwowyzv3k...@mail.gmail.com>: >>>>> On Thu, Mar 13, 2014 at 12:18 PM, Joshua Riffle <[email protected]> wrote: >>>>>> I'm aware this may not be the best mailing list to discuss something as >>>>>> generalized as best practices for LDAP structuring within OpenLDAP, but >>>>>> would anyone be able to direct me to a mailing list that would be better >>>>>> suited for this kind of conversation? >>>>>> >>>>> >>>>> I think it's an excellent discussion and I don't see why this list >>>>> cannot accommodate it. After all, OpenLDAP is currently a reference >>>>> model in the OSS world for LDAP so it could very well house discussion >>>>> around reference models for DITs. >>>>> >>>>>> I'm looking for any or all of these kinds of communications within a >>>>>> mailing >>>>>> list: >>>>>> >>>>>> Designing a person, account, group LDAP tree directory that would be >>>>>> scalable and flexible enough to grow to large sizes (millions) and still >>>>>> have a grip on best practices for identity management on an enterprise >>>>>> level. >>>>> >>>>> Usually you should aim towards a DDS (Distributed Directory Service) >>>>> and all nodes sharing some sort of agreement in the DIT structure >>>>> although it's not alway necessary. >>>>> >>>>>> Specifically for an educational institution if I can share the aches and >>>>>> pains of other directory owners with similar problems. >>>>>> I also am trying to prove / disprove the use of having a person directory >>>>>> object with multiple child account objects as good or bad architecture >>>>>> and >>>>>> understand why. I've never seen this discussed in practice. >>>>> >>>>> Most LDAP implementations are quite poor and revolve around Posix >>>>> and/or Windows AD management instead of using more elaborate DIT >>>>> modelling , aliasing, and the entryUUID operational attribute (RFC >>>>> 4530). The DIT model is unique to every application but I do agree >>>>> with you that we should have some reference models that break the >>>>> traditional People, Computer Group paradigm. >>>>> >>>>> RDN and DN are actually quite malleable and should never be used as >>>>> unique identifiers of any sort, but rather as temporary >>>>> addresses/names to locate entries, much the same way a person may have >>>>> different addresses throughout his life yet remain the same person >>>>> (aliases to a single entry/entryUUID). By the same token, two people >>>>> may have identical attributes, yet be two distinct individuals >>>>> (distinct entries/entryUUID). This can also happen in an LDAP DIT as >>>>> the LDAP specification purposely makes no effort in preventing or >>>>> controlling this. Moreover, the entryUUID is the perfect "key" to >>>>> integrate your LDAP technology to other data sources that may need to >>>>> "link" with the LDAP. So long as your tools actually use moddn and >>>>> modrdn (as opposed to deleting and re-creating the entry) then the >>>>> entryUUID should never change for the life of the entry regardless on >>>>> where it's located in the DIT. >>>>> >>>>> >>>>>> Good and bad ways to relate tree objects with each other. I only know of >>>>>> parent / child tree relationships or more "softly" by using DN's within >>>>>> an >>>>>> attribute like the group-member relationship. >>>>>> >>>>> >>>>> There are two popular and generic reference models for LDAP DIT >>>>> hierarchies: (a) the more traditional X.500 form, and (b) the more >>>>> modern domain-based around the DNS model. Each one is just a general >>>>> guideline and they are by no means strict models for any LDAP >>>>> implementation. In fact, the whole idea behind X.500 and LDAP is >>>>> precisely that the model is flexible and adaptable over time, meaning >>>>> that you don't have to "get it right" from the start and should be >>>>> able to evolve your DIT over time, provided of course that your >>>>> toolset is adequate. Web-based tools such as LAM for example are >>>>> almost hard-wired into a People, Computer, Group paradigm whereas >>>>> tools like PHPLDAPAdmin are more flexible but less intuitive. The >>>>> latter provides a template mechanism which allows for easy >>>>> customization to a particular implementation, but I think both (as >>>>> almost all popular LDAP browsers/admin tools) are dumb in terms of >>>>> moddn and modrdn so you need to hack them to work correctly with more >>>>> complex implementations. >>>>> >>>>> Anyway, the point is that your entries should be organized anyway you >>>>> want. I have done implementations where we can actually traverse the >>>>> DIT in a hierarchical manner (e.g. by units and departments with >>>>> people at different levels of the tree) but that can ALSO be queried >>>>> by means of a common attribute(s). So you can actually have it both >>>>> ways. I always prefer to model the DIT to reality and then group the >>>>> entries by attributes to simplify queries. This gives you the best of >>>>> both worlds as you can query at any level/branch and also allows to >>>>> implement a DDS more easily. Actually I encourage mixing the X.500 >>>>> with the Domain-based >>>>> >>>>> We have a very well documented reference implementation for an >>>>> educational institution and we would happily share in a Wiki >>>>> somewhere. Perhaps we can find a place where people can contribute >>>>> reference implementations for different implementations and that >>>>> allows for discussions, etc. Any idea where to post these?? >>>>> >>>>> >>>>> Best, >>>>> Alejandro Imass >>>>> Yabarana Corporation > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/
