[Fedora-directory-users] Ideas for fds

[jclowser at unitedmessaging.com]

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users