[Mailman-Users] Mailman on Solaris-based web server

[Brad Knowles]

At 12:17 AM +0100 2004-10-22, Richard Barrett wrote:

>  1. handling of files containing messages queued for processing as they
>  are moved along the chain of queues from initial delivery by the MTA
>  to handoff to the outbound MTA and to the archiver. The code in
>  $prefix/Mailman/Queue/Switchboard.py provides the enqueueing and
>  dequeueing functions.

	That's fine once the message gets to Mailman.  This means that 
your MTA queues (and probably your user mailboxes, unless you use an 
NFS-friendly storage method for them as well) should be on local 
filesystems, however.  If the server goes down, you risk losing those 
messages which are in the MTA queue but haven't been delivered yet.

>                         It appears to me that the operation of this code
>  avoids dependence on file system locking during both file creation and
>  deletion and is intentionally unaffected by a decision to use NFS mounts
>  as the storage for Mailman's qfiles.

	If Mailman does work this way, then this is very good news.

>                                        The residual risk is of collisons
>  in generating the file names of queued messages files using SHA digests
>  but I think this is fairly small.

	Agreed.  Since we're not talking about crypto applications here, 
we could probably even use MD5 hashes reasonably safely without 
having to worry too much about the unlikely collisions.

>  2. handling of files containing per list related data structures and
>  productions of archiving processes. These operations are protected by
>  a list locking scheme implemented using the code in
>  $prefix/Mailman/LockFile.py The comments in this module suggest that
>  specific efforts have been made to avoid deficiencies associated with
>  NFS mounted file systems but there are cautionary notes such as
>  ensuring that clocks on the systems concerned are adequately aligned.

	Also good news.  Also points out another known issue with NFS 
filesystems, and good server timesync is a very important issue that 
I am also involved with (see 
<http://ntp.isc.org/bin/view/Main/ContributorsList>).  Indeed, it was 
my involvement with NTP that brought me to Mailman, since we were 
running our mailing lists at the time with Majordomo and I wanted to 
move to something that would be easier to manage.

>  My own, non-expert conclusion is that
>
>  a. Switchboard.py's code sidesteps any requirement for fine grain
>  locking of individual message files when the are being queued and
>  dequeued and this avoids deficiencies NFS might have in this respect.

	That is a likely conclusion.

>  b. The coarse grained locking used for protecting per list related
>  data structures and archiving operations specifically addresses
>  known deficiencies in NFS.

	Also likely.

>  It seems to me that your reservations are reasonable but it is clear
>  that the authors of this part of Mailman (all smarter men than I) were
>  conscious of the potential problems and have made efforts to avoid them.

	Barry (and the other Mailman developers) are most certainly not 
dummies, but I wasn't aware that this was an issue that they had 
specifically looked into carefully and make significant efforts to 
try to deal with.

	This is very, very good news.


	Thanks for the update!

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.