Granted that there are some issues with the solution. It
will work well for small to medium sized organizations.
This solution (as I've noted) is not for scalability, but
for compatability. I did some testing, and was able perform
crud operations on both NS4 and OpenLDAP2 with groups of
up to 50k members. I won't say retrievals are lightening
fast, but they are reasonable. Not recommended for heavily used
directories. Might be a decent idea to have a dedicated replica
for these types of queries.
Granted, and I agree that generating lists of users based on
an attribute value on the user entry is much better. But this is
not compatible with the way many products manage groups. There
are also administratively defined limits on the number of entries
returned. Unless you bind as your administrative user, if you've got
large groups then you're also going to bog down the directory server.
The ideal solution is a mailing list manager that can generate,
from time to time, a list from LDAP and cache it. Then the
list can be mailed frequently without much penalty on the LDAP
side. I'm going to have this built into our MLM package. For
smallish groups I'd be nice to have it handled by the MTA. I
can certianly understand if there is enough argument against
it or the community doesn't have the interest.
David Boreham wrote:
and groupofuniquenames are such classes. They contain member
and uniquemember attributes. These attributes are distinguised
name for entries. Each entry is a member of the group. I'd like to
Note that most (all?) LDAP servers do not implement static groups
efficiently for large groups. When I worked on the Netscape LDAP
server we constantly had to tell customers not to do this because beyond
a few thousand members, the server will bog down serving and modifying
the group entry. A design where each user entry has an attribute containing
the name of the mailing lists to which they subscribe is much more scalable.
Last time I looked OpenLDAP had the same problem, they're both
derived from the original UMich code.
YMMV of course.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
--
Andrew Libby
CommNav, Inc
http://www.commnav.com/
717.506.1112
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
