 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
15 messages in net.sourceforge.lists.courier-usersRE: [courier-users] LDAP aliasing| From | Sent On | Attachments |
|---|---|---|
| Saxon Jones | Jan 21, 2005 12:43 pm | |
| Sam Varshavchik | Jan 21, 2005 4:54 pm | |
| Zenon Panoussis | Jan 25, 2005 11:49 am | |
| Sam Varshavchik | Jan 25, 2005 3:57 pm | |
| Zenon Panoussis | Jan 26, 2005 5:43 pm | |
| Sam Varshavchik | Jan 26, 2005 5:50 pm | |
| Laurence Moore | Jan 26, 2005 5:55 pm | |
| Sander Holthaus - Orange XL | Jan 26, 2005 6:36 pm | |
| Sam Varshavchik | Jan 27, 2005 7:42 pm | |
| Robert Pfister | Jan 28, 2005 12:57 am | |
| Sander Holthaus - Orange XL | Jan 28, 2005 6:12 am | |
| Saxon Jones | Jan 28, 2005 2:54 pm | |
| Zenon Panoussis | Jan 29, 2005 12:22 pm | |
| Saxon Jones | Feb 3, 2005 3:25 pm | |
| Sam Varshavchik | Feb 3, 2005 3:56 pm |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | RE: [courier-users] LDAP aliasing | Actions... |
|---|---|---|
| From: | Robert Pfister (x1pf...@adelphia.net) | |
| Date: | Jan 28, 2005 12:57:42 am | |
| List: | net.sourceforge.lists.courier-users | |
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: cour...@lists.sourceforge.net [mailto:cour...@lists.sourceforge.net] On Behalf Of Sam Varshavchik Sent: Thursday, January 27, 2005 4:56 PM To: cour...@lists.sourceforge.net 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.