jclowser at unitedmessaging.com wrote: > Netscape roles are great, but the reason I don't prefer them (and > dynamic groups) is that it is very implementation specific - i.e. > netscape/sun/fedora directory server (I'm considering them all more or > less the same) is the only server that implements it. If I depend on > it, I'm tied to a particular implementation of ldap server, and can't > go to openldap, active directory, joes directory, etc (not that I'd > want to - esp ad, but for the sake of the whole standards argument, > it's important to consider and I'd want that option). > If I have a dynamic group that returns members in uniquemember, I > could always switch, without changing my apps, with the caveat that > the groups may have to be managed statically. I suppose you could say > the same about nsroles, but that further assumes an app allows you to > define the search filter. I actually used a static method very > similar to nsroles before nsroles existed (i.e. create an entry in > ldap, then create an attribute in the users entry that contains the DN > of that entry, and use that to determine what roles a user is part of, > solely by looking at the users entry. Nice 'cause you could config > referential integrity to clean it up and all if you delete the role, > too). But I ran into the same problem - only the apps I wrote knew > how to use it (but at least it worked in any ldap server :) ). At > least it didn't have the resource limit issues that groupofurls has. > > Anyway, the issue of large groups does exist for me, so it is a > concern - A customer of 100k-1 million or more is not out of the > question. It would have to be used with care. But, in the case of > smaller deployments, or even smaller or "select" groups, it would be > useful to have this for cases where I can't make apps use the Netscape > extensions. In a lot of cases, the _app_ doesn't need to deal with a > large list of returned values - i.e. if I do a search for > (&(cn=MyGroupName)(objectclass=groupofuniquenames)(uniquemember=<someUserDN>)), > returning say, only the cn attribute or discarding everything but a > found/not found result to see solely if I'm a member, I would want it > to work. Some apps use this to determine group membership, and can't > be changed... This is actually the more likely scenario than wanting > to use/display the entire list. > > Haven't really thought this through, but would it be possible to use a > combination of roles and cos to create a group the way I am > suggesting? I would think even if possible, it would be complicated > and probably pretty inefficient, but is an option. If I remember > correctly, you can't search on dynamic attributes generated by Cos, > though (actually, I think in the most recent version of the Sun DS, > you could search on them, but they are treated as unindexed > searches)... This would likely factory into the members dynamically > returned as uniquemember idea as well, so one more inefficiency in > implementing my idea :-D In Fedora DS these attributes are "indexed" so you can search on them very quickly (e.g. ldapsearch .... (nsrole=ROLEDN)). But, point taken. Roles work great, but they don't conform to the standard group schema. We could use our roles/cos technology to implement a very efficient static group. One problem remains though - how to solve the problem of retrieving a large static group? > > - Jeff > > > > David Boreham wrote: > >> I should also say that the roles feature was born at a time >> when the product was marketed for very large scale deployments. >> We had seen for example the mail server users attempt to create >> groups with millions of entries. That just didn't work at all well. >> >> That was then and this is now: the target market is somewhat >> different. For the typical F500 company with a few thousand employees, >> virtual view static groups are probably just fine. >> >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20050610/99347aed/attachment.bin
