[Fedora-directory-users] Ideas for fds

jclowser at unitedmessaging.com jclowser at unitedmessaging.com
Sat Jun 11 07:32:10 UTC 2005


David Boreham wrote:

> Are there really large numbers of applications deployed that
> grok static groups ? I'd like to hear about them because I can't
> remember ever seeing one. Mind you I don't get out much ;)

Hmm - good question.  I've been working with nsds since 1.0, and over 
that time, it comes up every so often, but I couldn't give you a big 
list of apps that exist now :)

One simple realworld example I run into:
- I want to create a group of people.  Lets say I want this to be all 
people in the engineering department, which is determined by having the 
value "engineering" in the department attribute of their entry.
- I want to use that group as a mail group in Sun JES (or Netscape) 
messaging server.  I can create a groupofURLs style group that the 
Messaging server will use to determine members of the email list, based 
on an appropriate filter.  As a dynamic group, it maintains itself (sort 
of - I guess it's more a matter of a client that knows how to interpret 
it).  Messaging server also recognizes uniquemember values as members of 
the list, so if that were dynamically generated, it would work in place 
of groupOfUrls.
- Further, I want to set up a webpage in Apache that only the 
engineering group can see.  Apache doesn't deal with groupOfURL style 
lists, as far as I know, so this doesn't work. (groupOfURLS being ok for 
finding a list of members, but lousy for determining if a user is a 
(dynamic) member of it)  Nsroles would probably work for apache, but I 
don't think JES/Netscape messaging supports nsroles as a means for 
defining mail groups - its not really appropriate for determining lists 
of users like this.

Ignoring for the moment that JES messaging is pretty much tied to one 
ldap implementation (i.e. the Sun JES Directory server), I want to use 
the same group across apps, because I don't want to have to maintain 2 
versions representing the same group information and possibly have them 
out of sync.  Also, I want to be able to send email notices related to 
the engineering web page, targeted at those users that have access to 
it.  I _could_ define the same LDAP URL in apache for access to the web 
page - i.e. ignore the group and just use the same or similar LDAP URL 
that I used in the mail list for apache .htaccess files.  But... if I 
later change the group filter in LDAP - say I make the filter 
(|(department=engineering users)(department=engineering staff)), if I 
don't remember to go back and change things in apache everywhere it's 
defined, I loose consistency.

Maybe the best solution would be to create a single ldap entry that is 
groupOfUrls, inetMailgroup (JES mail list), and a dynamic nsrole group, 
so that one entry defines the same list of users in multiple ways that 
each app can find.  At least having this all together means that if I 
change my filter, I will see all the filters/methods in one place, so in 
my above example I won't have to go find all my apache .htaccess files.

One last thing to keep in mind - nsroles and groupOfUrls is a 
netscape/sun/fds schema extension.  If I want to keep an app portable, 
so that I can drop in openldap, FDS, AD, etc without having to go back 
and change all my apps, nsroles and groupOfURL's don't work - is there a 
way that is consistent across ldap implementations?  With a "dynamic" 
groupOfUniqueNames, this would be portable, though on other ldap 
implementations, my list may have to become static if the replacement 
ldap implementation can't generate it on the fly.

I guess what I am really lookig for is a standardized way to define a 
dynamic group that works consistently across applications (and is 
"portable" across ldap implementations).  groupOfUniqueNames fits this 
for static groups, but there is nothing that fits this for dynamic groups.

Does that make sense?  Any ideas on solutions, or am I asking too much? :)

Anyway, sorry for beating this horse to death...

 - Jeff




More information about the Fedora-directory-users mailing list