We are configuring three F330s into our enterprise architecture to serve /home data to our users. We currently use SparcServer 1000s for this purpose. We are interested in how other organizations are implementing UNIX mail in this situation. Is it best to put /var/spool/mail on the NetApp filers or keep it on the UNIX mail server?
Thanks.
+--- In our lifetime, "John F. Kane" jkane@mitre.org wrote: | | We are configuring three F330s into our enterprise architecture | to serve /home data to our users. We currently use SparcServer | 1000s for this purpose. We are interested in how other | organizations are implementing UNIX mail in this situation. | Is it best to put /var/spool/mail on the NetApp filers or keep | it on the UNIX mail server?
Depends on how many accounts you have. Having a /var/spool/mail with 30,000 entries will definitely hurt performance. It also depends on how many boxes would be accessing the mail spool (locking issue). Also depends on what kind of mail volume you move.
This subject has been touched on quite a bit in the comp.mail.sendmail group. There are many ways of solving all the inherent problems, including delivery of mail to home dirs (savings on the STAT) as well as delivery to 1 file per message rather than 1 big mbox (saves on locks).
At my previous employer we went to an NFS mail architecture based on an f540 and a few pop and smtp boxes sitting in front of it. Worked very well (but there was alot of backend development work that went into the delivery mechanism). At the time we did have 100,000+ mail accounts... :) Check qmail for some additional info.
Depends on how many accounts you have. Having a /var/spool/mail with 30,000 entries will definitely hurt performance. It also depends on how many boxes would be accessing the mail spool (locking issue). Also depends on what kind of mail volume you move.
One of the main advantages of the filer is that it supports directory hashing to speeds lookups greatly. This has been a feature since 2.1; there's a white paper on the web site that talks about it. You are definitely better off having 30,000 files in one directory on a filer than having it on a local UFS disk...
Some rules of thumb to follow:
1. Configure your clients so all email is delivered from one central mailhost (which then writes to the mail spool over NFS). The other clients will read from it and re-write their own mailboxes, but delivery by the local agent (usually /bin/mail) is best left to only one machine.
2. Mount /var/spool/mail with the "hard" option... this prevents timeouts in case of overload.
3. Mount /var/spool/mail with the "noac" option... this is not necessary, but it is recommended. In fact, if you don''t do this, Solaris will execute the following code at startup:
/usr/bin/logger -p mail.crit "WARNING: /var/mail is NFS-mounted without setting actimeo=0," /usr/bin/logger -p mail.crit "this can cause mailbox locking and access problems."
4. Upgrade to the latest version of sendmail... vendor-supplied sendmails are often extremely buggy.
Bruce
Bruce Sterling Woodcock penned:
- Upgrade to the latest version of sendmail... vendor-supplied sendmails are often extremely buggy.
Not to mention extremely insecure.
Regards,
David K. Drum david@more.net -- "That man has a rare gift for obfuscation." -- ST:DS9 * "It's hard to be bored when you're as stupid as a line." -- Vernor Vinge * "Reality has a tendency to be so uncomfortably real." -- Neil Peart * "You can only measure the size of your head from the inside." -- Larry Wall
One of the main advantages of the filer is that it supports directory hashing to speeds lookups greatly. This has been a feature since 2.1; there's a white paper on the web site that talks about it. You are definitely better off having 30,000 files in one directory on a filer than having it on a local UFS disk...
Some rules of thumb to follow:
- Configure your clients so all email is delivered from one central mailhost (which then writes to the mail spool over NFS). The other clients will read from it and re-write their own mailboxes, but delivery by the local agent (usually /bin/mail) is best left to only one machine.
We're about to implement a system which uses several central mail servers, all sharing access to mailboxes. How have people handled this? The two options I've come up with so far are to use procmail as the local agent or to install qmail which uses a mail directory containing a single file per message.
The first approach isn't too much different from what we're doing at the moment on a single server, but I'm somewhat wary of trusting any sort of locking across NFS. The second involves migrating from sendmail to qmail, which I'm not overly keen to do. It would be straightforward enough if all of our end-user email access was restricted to POP3 (qmail includes its own POP3 server), but we've a considerable number of IMAP users to worry about...
Are there any other alternatives?
+--- In our lifetime, Ronan Mullally ronan@iol.ie wrote: | | | options I've come up with so far are to use procmail as the local agent | or to install qmail which uses a mail directory containing a single file | per message.
Ack! procmail in large installations is evil. We went that route a long time ago. I have hated myself ever since. If you have a large volume of mail deliveries, imagine having to spawn a large process for each piece of mail you deliver. Yowsa. It really killed our mail machine after some time. The reason we went with it (at the time) was because we were doing a BSD -> Solaris transition and had not spent enough time on the delivery agent (we also started doing home dir mail delivery in this transition). procmail is cool for filtering and some other things.
better choice is to hack mail.local (or the delivery agent of your choice) to do what you are trying to acomplish.
Yes, this really has deviated from talking about filers.
Alexei
-
alexei＠cimedia.com -
David Drum -
John F. Kane -
Ronan Mullally -
sterling＠netapp.com