On Tue, Nov 29, 2005 at 09:54:30AM -0600, scott hollatz wrote: >> we are thinking of moving our unix style mailbox format imap server :- >> >> IMAP4rev1 2004.357 >> >> on to a Linux box with mail still being delivered by smtp to the Solaris box. >> >> Could anyone with experience of running imap over NFS please comment on their >> experiences pro and con, especially in the realm of locking. > >Many years ago we experienced similar problems with NFS. > >The use of NFS made sense under a simpler email services architecture but >begain to fail (i.e., poor IMAP/POP services) as load and user base grew; ...
Well, same here, nearly. The problem of 'locking' is not so much depending on UW-IMAP as on which *combination* of tools runs on which side of the NFS! You have to make absoutely sure that every tool working on an mbox file is using the same locking (or at least is locking 'somehow' against every other tool). As there are three typical 'locks' - network-locking for NFS - kernel locking for files - dotlocks (which are th 'lockfiles' named '<box>.lock') you'll habe to find out which way is the safe way. We here have working (but will move away from soon ...) A Solaris 9 (SunOS 5.9) Server with local spool files which are exported via NFS to the Workstations, and 'Home-Servers' which export User-Homes to the Mailer. This results in: - UW-IMAP (and pop) for remote access on MTA-local-Spool and on Remote(NFS)-Home-Files of users., - The /var/mail/mailbox-files exported via NFS for local old programs - 'qmail' for the MTA delivering via 'procmail' because 'qmail' ***NEVER*** works directly on NFS!!! - Mail delivered via procmail directly over NFS into Homes. 'procmail' and 'UW-Imap' and 'pine' work absolutely correct together. 'mutt' and 'SUN's [dt]mail' seem to be secure too, others we did not check completely as they mostly allow access via IMAP. We seldom (but not 'never'!) see mailbox corruptions. More often we see (network/NFS-)locks hanging 'forever' which mostly means a dead machine holding a nfs-lock. Even more often we see procmail-sorted deliveries into 'remote and hanging NFS-Homes', which then block all available delivery-'slots' of qmail, which brings the Mailer to a full stop(!). The latter scenario causes us to move away from the old system to 'only IMAP' via 'Cyrus' (cyrus does allow 'folders with mail AND folders in them' and thus is more Win*compatible) and away from qmail because we need some newer MTA features. (programmable retry times, authentication schemes, ...) Stucki -- Christoph von Stuckrad * * |nickname |<[EMAIL PROTECTED]> \ Freie Universitaet Berlin |/_*|'stucki' |Tel(days):+49 30 838-75 459| Mathematik & Informatik EDV |\ *|if online|Tel(else):+49 30 77 39 6600| Arnimallee 2-6/14195 Berlin * * |on IRCnet|Fax(alle):+49 30 838-75454/ _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
