I wrote the current patch, and have some pride-of-ownership to this, but also some real-world experiences. I don't how my setup compares to other courier installations, it probably isn't the largest, but it is big enough to get a a flavor for any issues.
This has run on two machines for the last 6 months: * 300 users, OpenLdap, ~10,000 msgs/day * 1000 users, NDS, ~50,000 msgs/day Both are server-class 2-cpu machines, 4gb memory, and have LDAP running on the same server over localhost. Some operational observations: * Neither machine is ever CPU bound. * 300 user machine open LDAP machine has absolutely no issues * 1000 user NDS machine needs bi-weekly reboot, as there is a memory leak somewhere that causes the machine to eventually go into swapper heaven. Restarting courier, or NDS doesn't seem to fix it. Probably not related to LDAPALIASD or the patch. * we get occasional crashes on ldapaliasd on NDS machine, this could be caused by the extra load put on NDS, a memory leak in the recursive patch, or some functional defect. It is a cause for some concern. Observations from a support organization perspective: * A nested alias ability helps better organize the distribution lists, and other forwarding. * Requiring a maintainer to login into a unix system to edit and rebuild the alias file means I can't delegate this task to a less unix-savy resource. I found that rebuilding the alias file was a step that was often overlooked -- this caused lots of frustration all around. * I can expect even a junior staff member with minimal traing/documentation to update aliases with PhPLDAPadmin. In my circumstances, the extra machine resources were not an issue. Robb -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Varshavchik Sent: Thursday, January 27, 2005 4:56 PM To: [email protected] Subject: Re: [courier-users] LDAP aliasing Sander Holthaus - Orange XL writes: > Yes. I and a few others asked this question before. I bookmarked the > address for the patch, http://home.earthlink.net/~x1pfister/courier/, > but it doesn't seem to exist anymore. > > Sam, couldn't something like this be implemented in Courier? Though it > will cause some extra overhead, it shouldn't be too much and if people > can define how recursive it is allowed to be (e.g. > LDAP_RECURSION_DEPTH = 0 for disallowing recursion, 1 for allowing one recursive call, etc). The problem is that resolving recursive aliases introduces a lot of additional complexities into the alias resolution process. As a persistent daemon process, courierldapaliasd is very long lived. Long-living daemons, like courierldapaliasd, should avoid using dynamic memory allocations as much as possible. courierldapaliasd uses none, except for whatever happens in the standard C library, and OpenLDAP, which I can't do anything about. There are a number of technical reasons for that. Plus, I have to question whether it is proper to have recursive LDAP aliases in the first place. That means that, for example, an alias that expands out to a hundred addresses will cause a hundred additional round-trip LDAP lookups. Every time. This does not sound like a right design to me. It makes more sense to me to have all the recursive alias resolutions done once, and save the expanded alias list in the LDAP directory. This is exactly how Courier's native mail aliases work. With native aliases, I don't look up every address every time. The makealiases script reads the alias file, expands all aliases recursively, and builds a GDBM/DB database where the aliases are already expanded. This eliminates a lot of waste from the code that receives new messages. Only a single lookup is required for an E-mail address. An LDAP-based setup should be structured in the same way. ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
