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
