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
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
