Great Circle Associates List-Managers
(February 2005)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: A vote for Majordomo
From: Jonathan Knight <jonathan @ cs . keele . ac . uk>
Date: Fri, 4 Feb 2005 15:24:15 +0000 (GMT)
To: sdean @ bard . edu (Stewart Dean)
Cc: list-managers @ greatcircle . com
In-reply-to: <42038024.6030709@bard.edu> from "Stewart Dean" at Feb 04, 2005 09:01:08 AM



I just read your mail with my mouth open going "what?!?".  Having run
both majordomo and mailman I was having trouble believing what you were
saying.

I run around 4000 mailing list for 13000 users in a University.  We used to
run majordomo, but the amount of systems admin work that needed doing was
just getting ridiculous.  Majordomo was showing up a few bugs and I wasn't
happy jumping from majordomo 1 to 2 as 2 didn't have an official release.

I went for mailman and since then my life has got much simpler and I've had
much greater reliability and the users have had much more functionality.


> One of the top two or three requirements for a software package to me 
> has to do with quick, clean, little-or-no-impact-to-the-users upgrades. 

Yes?  I will admit that majordomo 1 didn't need much upgrading.  That was
because it had been abandoned and bug fixes were passed around in email
messages rather than being rolled into a release.

I've done one upgrade to mailman in 3 years.  The underlying linux is
updated using yum every week and I've had no failures.  I was aware that
upgrading might be risky and so I took some care to minimise teh risk.
1.  I built my own version of apache and put it in /usr/local/mailman.  I took
    out everything that wasn't strictly needed for mailman.
2.  I built my own python in the same way.
3.  I built mailman to use my python and apache

So my mailman, apache and python aren't hit by linux updates and I can
upgrade when I want to.  Upgrading is also quite simple.
1.  Stop email and web
2.  tar up /usr/local/mailman as a backup
3.  Install the updates
4.  Check everything and run some test email
5.  Turn email and web back on

If it all goes pear shaped I can remove /usr/local/mailman and untar my
backup to return to the normal state.  No fuss and no bother.

As a bonus we use "exim" http://www.exim.org/ as our mail system which has a
gadget to detect mailman lists automatically.  This means adding or removing
a list only requires a single command and no fiddling with alias files.


As creating and deleting mailing lists is that one command, our operations
staff now do that job.  Everything else is done via a web page by the
mailing list owner so i don't have to do any of that either (majordomo 1
used to require emailed text files which mystified windows users).  Mailman
has enough functionality to remind everyone what they are supposed to be
doing by email which avoids me having to remind them.


All in all our mailman system just sits there and works and the only
workload I have is to settle disputes on moderation decisions.



-- 
  ______    jonathan@cs.keele.ac.uk    Jonathan Knight,
    /                                  Department of Computer Science
   / _   __ Telephone: +44 1782 583437 University of Keele, Keele,
(_/ (_) / / Fax      : +44 1782 713082 Staffordshire.  ST5 5BG.  U.K.


References:
Indexed By Date Previous: A vote for Majordomo
From: Stewart Dean <sdean@bard.edu>
Next: Re: any recent reviews/roundups of list management sw
From: Vivek Khera <khera@kcilink.com>
Indexed By Thread Previous: A vote for Majordomo
From: Stewart Dean <sdean@bard.edu>
Next: Re: A vote for Majordomo
From: J C Lawrence <claw@kanga.nu>

Google
 
Search Internet Search www.greatcircle.com