jclowser@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
