
On 9/6/07, Patrick M. wrote:
Thanks for the detailed explanation. One thing to mention is that this mail server is pushing close to 1 million e-mails a day, and has no issues with that whatsoever.
I was the Sr. Internet Mail Admin for AOL. We regularly did several million mail messages per day, after filtering out 95-99% of the incoming flood as spam. One thing I learned is that, many times when you have a problem, it's with a part where you think everything is okay.
I'm not saying that I'm definite you're wrong about this, I'm just saying that you shouldn't necessarily be making any assumptions about where your problems lie, but you should instead be prepared to measure and be certain.
Both mail servers mount the /home for
the usernames, and everything is stored in Maildir. I'm almost positive there are no issues with NFS itself, as all other mail works just fine.
One line I frequently hear is "It works just fine in Windows, so obviously your Unix box must be broken". Riiiiiiiiiight.
Sorry, this is a pet peeve of mine, especially when it comes to something like Maildir.
Part of the problem is that Maildir does a number of things that are not necessary in order to solve the problem(s) it was trying to solve, and it doesn't fully solve even those issues. Meanwhile, it introduces a whole host of new issues, and this makes Maildir a much less than ideal solution for the problem.
There are other mailbox directory solutions which really do resolve the issues in question and without introducing a whole host of new problems to deal with.
Again, I'm not saying you should be forced to switch, just that you should be aware of the potential issues with your chosen solution, and you should be able to fully troubleshoot and deal with those problems.
Mailman is installed on both mail servers. /usr/lib/mailman is NOT NFS mounted (meaning its installed on both machines), however I've NFS mounted the /var/lib/mailman directory, where all the lists and such are.
This is sounding like a binary package install version of Mailman. That's not where we put things in the source version from the gnu.org/lists.org website.
In our version, you can put all of /usr/local/mailman on NFS, and as well as NFS can be made to work for anything, it should work for Mailman. This includes the Mailman queues as well as the archives, the source code, the compiled-on-demand object code, the whole kitten-and-caboodle.
Now, with that being said, you mentioned that Mailman can be unfriendly when placed in an NFS environment. How can I test to see that it is an NFS issue with Mailman?
It's not Mailman per se. It's *anything* on NFS. Mailman will work about as well on NFS as anything else can possibly work on NFS, but simply throwing NFS into the mix is likely to cause a whole host of new issues that you're going to have to deal with that other site administrators might not.
These aren't Mailman problems per se, but NFS problems that cause problems with applications running on NFS, such as Mailman.
Now, your NFS server will have a huge impact on what problems you see and what tools you have available to you to help resolve those.
Generally speaking, if you're using high-end equipment like Network Appliance, EMC, or Hitachi Data Systems, then if you have any problems you should be talking to your account representative and your support team. They're going to know much more about your hardware than we do, and they should know enough about your application to be useful.
NetApp, EMC, and HDS have gotten their stuff down to the point where Oracle actually certifies their products as being suitable for use on these servers, whereas Oracle explicitly rules out any support for their products on other NFS servers. There's a reason for this.
So, the hardware you have available to you will have a huge impact on your systems.
I'll take a look at those docs and reply back to here. Thanks again.
If you have specific questions, please let us know.
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>