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
- 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
