[Fedora-directory-users] Ideas for fds

[Richard Megginson]

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://listman.redhat.com/archives/fedora-directory-users/attachments/20050610/99347aed/attachment.bin>