[Fedora-directory-users] Ideas for fds

[jclowser at unitedmessaging.com]

Pete Rowley wrote:

>I seem to have missed the start of this thread, so apologies for replying to
>both posts here: 
>  
>
The thread started with looking for a solution to a "simple" problem (of 
course) :)

Basically, if I have an application that looks for members of groups for 
things like authentication and access control, it's common for that app 
to look at something like 
(&(objectclass=groupofuniquemembers)(dn=<usersdn>)) to determine if they 
are a member or not.  In many cases, the apps have this hardcoded and 
don't allow the filter to be changed.  Alternately, they may read these 
static groups for things like determining a list of members to send mail 
to (if they are used as mail lists, for example).

In some cases, these groups change often, and/or are burdensome to 
manage statically, so it would be nice to set them up as dynamic 
groups.  nsRole and groupOfURLs provides this functionality, but is 
incompatible with the above apps, so you have to fall back on static lists.

Was just saying it would be nice to be able to support dynamic lists in 
such a way as to be compatible with apps that only know how to check 
static groups.

I know there are a lot of issues related to performance, etc, but it 
would be nice if there was some way somewhere to deal with this 
problem.  Anyway, just wanted to through this out there for discussion, 
and see if it could be done, if others had dealt with this, come up with 
alternate solutions that work in the above case, etc (one solution I've 
implemented in the past was to create a custom "dynamicGroup" 
objectclass inherited from groupofuniquenames, which had a memberURL or 
similarly named attribute, and then had a nightly script that ran the 
ldap url and populated uniquemember).  'Course, that has obvious 
limitations, such as the list not updating often enough, and still has 
the problem inherent in large lists.

Maybe FDS will be accepted widely enough that other directory servers 
and apps will start supporting nsrole and/or groupOfURL's and this will 
become a moot issue (though groupOfURL's has it's problems as well)  :)

>This crops up every now and then and for the reasons given I (and others)
>have fended it off.  I am always weary of performance expectations with
>feature requests and it is probably unlikely that an implimentation like
>this would equal static group performance let alone roles performance.  As
>others have said, those potentially huge attribute value lists are a major
>issue - just moving that data around on the server side is burdonsome.
>  
>
Agreed - I understand some of the overhead in this, and that it would 
have an impact (esp vs true static groups), but if used carefully... 
'Course, as soon as you implement it, there will be people that abuse it 
and/or do not understand the caveats involved in using it, and you get 
hammered for implementing something that has poor performance :)

>Having said that, I did consider what would be required to do this.  If you
>required a two way relationship where the static groups could be updated old
>style then you would need to make virtual attributes writeable - not a slam
>dunk by any means.  If you just wanted readable entries then that is
>possible, but not the way you suggest.  You would be far better off creating
>a new virtual attribute service provider designed for the purpose than
>retro-fitting the functionality into roles.  It could key off the nsrole
>attribute and/or interpret dynamic groups.
>  
>
Well, I was thinking along the lines of the behavior of CoS, where you 
can read attributes that may have generated values, you can write to it 
(and I believe the static and dynamic values are either merged or one 
takes precedence - been a while and I forget the behavior).

>>In Fedora DS these attributes are "indexed" so you can search 
>>on them very quickly (e.g. ldapsearch .... (nsrole=ROLEDN)).
>>    
>>
>
>When did indexing get added? :)
>
>  
>
Um... maybe I'm mixing up some of the differences that happened after 
the Netscape/Iplanet/SunONE/JES/name of the day split happened, and this 
is only in the latest Sun release :-D (or was that even something that I 
said?).

 - Jeff