[sf-lug] looks like the 1s have it

[Rick Moen]

Quoting Jim Stockford (jim.stockford at gmail.com):

> i generally introduce myself as a nearly perfectly
> lazy whore. whore == rent my body for money
> (or food); taos has pimped me out to walmart.com.
> lazy == littlest work, mostest eating and laughing.
> my RH affinity is so motivated.
> 
> i'm much more philosophically inclined to debian,
> but the lazy whore is hard to budge: you claiming
> that it'll be significantly easier on debian and you'll
> answer at least some of my pleas for help?

Well, no and yes.  Yes and no.  I was being about 50% facetious.

> if so, i'll build a box.

Oh, I'll be glad to help you on any distro, actually -- or *BSD, or
Slowaris^WSolaris.  To the extent you end up moving outside my recent
experience, you might have to do some of the heavy lifting, though.
E.g., I respect the Postfix MTA greatly, but don't happen to have
personal experience with it.  My servers tend to be built with the Exim4
MTA, having done an emergency move from sendmail to its Exim3
predecessor (now discontinued) at a time of severe mail overload.  (Long
story, my personal shooting of my pedal extremities being a key part.)

Sysadmins tend not to stick with (e.g.) the same MTA out of brand
loyalty or affection, per se, but rather just re-use what's worked for
them and whose configuration can be copied.  If I had to construct a new
Apache httpd + MTA + Mailman setup, I'd (more or less) replicate mine
because that's the path of least resistance:  You'd end up with a Debian
testing/unstable box with Exim4.x, the EximConfig add-ons, Mailman,
and Apache 1.3.x.  (I don't object to Apache2 as much as early in its 
history, but it still strikes me as a textbook case of Second System
Effect.)

If I help you do something similar on an RHEL/CentOS box, I might at
points turn and stare blankly yet hopefully at _you_ on problems with
Apache2.x and with {sendmail|Postfix}.  If you're fine with that, I'm
fine with that.


There's one thing that Exim3/Exim4 does better (to the best of my
knowledge) than any other MTA: integration with Mailman.  Phil Hazel
(Exim author) coded a nice bit of "glue" where Exim can be configured to
read Mailman's list definitions directly.  When thus configured, Exim
need no special admin procedures to "see" new Mailman lists that you've
just created, and no special admin procedures to no longer "see" Mailman
lists you've just removed.

To my knowledge, no other MTA has that.  The config in question is
automatically present in Debian's packages; I don't know about other
distributions.  The fallback method for integration of Mailman with
MTAs, which when last I checked was still used by all non-Exim MTAs
and _might_ still be the default even with Exim on non-Debian distros,
is to add about half a dozen lines to /etc/aliases (and then re-run 
"newaliases") upon creation of each new Mailman mailing list, to
intercept mail to each list-related address and hand it off to the 
appropriate module of Mailman.

Debian strongly deprecates program-related lines in /etc/aliases for
security reasons (input validation), and to my knowledge you'd actually
have to go to some trouble to enable their processing (at least, in
Exim).


Anyhow, the _general_ nature of Mailman setup, phrased in a
distro-neutral manner, is like this:

1.  Do your general MTA setup.  Test, make sure it works OK.

2.  Do your general httpd setup.  Test, make sure it works OK.

3.  Install the Mailman package.  Make sure you have a suitable
    Python runtime + libraries.  (Mailman is written in Python.)

4.  Configure your httpd to include the "plumbing" for Mailman's
    CGIs.  For my Apache 1.3.x setup, that's stuff like this in
    /etc/apache/httpd.conf:

    ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/
    Alias /pipermail/ /var/lib/mailman/archives/public/
    Alias /images/mailman/ /usr/share/images/mailman/

5.  Create the Mailman-internal mailing list called "mailman", 
    which it uses for its internal records.  (This might happen
    automatically when you install the package.)  Customise 
    mm_cfg.py if you need to.  (That's the main Mailman config
    file.)  Start Mailman's qrunner daemon.

6.  Create one or more real mailing list.  (I always start with
    one called "test".)   One does this with the script "newlist",
    which is in the "bin" subdirectory of the Mailman base 
    directory.  About this time, you'll also need to figure
    out where the Mailman base directory is.  ;->  On my Debian
    boxen, it's /usr/lib/mailman.  All other Mailman stuff, 
    including the Web archives (archives/private and archives/public)
    are within that base directory.

    When you run "newlist", e.g., "cd /usr/lib/mailman; 
    bin/newlist test", newlist will do its job, and then advise 
    you of the exact half-dozen lines it thinks you should add 
    to /etc/aliases.  On my Exim4 system, I ignore those, because
    I know Exim4 automagically detects and handles Mailman list  
    addresses without help from the aliases file.  On a non-Exim
    or non-Debian system, you might need the aliases.

7.  Configure your new list(s) via the administrative Web screens, and
    then test them.  You're done!

The 50% that was non-facetious entailed (1) avoiding /etc/aliaseses
maintenance making your sysadminly life simpler, and (2) some other nice
defaults that keep the work minimal -- that in fairness _may_ be also
done by other distributions.

Big picture:  There's certainly nothing the Debian packages and their
defaults provide that a Scarlet Chapeau-style system can't.  If 
_personally_ asked to handle all the niggling setup details, I'd
initially be at a disadvantage.

Mind you, the above is just the first, suspiciously easy step -- in a
way.  That is, great, you have a running system with running mailing
lists.  Now, what are you going to do about the spam problem?  Keeping
mailing lists, and systems in general, spam-free without working
yourself to death and without interfering with legitimate mail is a
seriously difficult problem.  And there are other sysadminly joys.