After trying to read that, I think I pulled a groin while sitting down.<br><br><b><i>Rick Moen <rick@linuxmafia.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Quoting Jim Stockford (jim.stockford@gmail.com):<br><br>> i generally introduce myself as a nearly perfectly<br>> lazy whore. whore == rent my body for money<br>> (or food); taos has pimped me out to walmart.com.<br>> lazy == littlest work, mostest eating and laughing.<br>> my RH affinity is so motivated.<br>> <br>> i'm much more philosophically inclined to debian,<br>> but the lazy whore is hard to budge: you claiming<br>> that it'll be significantly easier on debian and you'll<br>> answer at least some of my pleas for help?<br><br>Well, no and yes.  Yes and no.  I was being about 50% facetious.<br><br>> if so, i'll build a box.<br><br>Oh, I'll be glad to help you on any distro, actually -- or
 *BSD, or<br>Slowaris^WSolaris.  To the extent you end up moving outside my recent<br>experience, you might have to do some of the heavy lifting, though.<br>E.g., I respect the Postfix MTA greatly, but don't happen to have<br>personal experience with it.  My servers tend to be built with the Exim4<br>MTA, having done an emergency move from sendmail to its Exim3<br>predecessor (now discontinued) at a time of severe mail overload.  (Long<br>story, my personal shooting of my pedal extremities being a key part.)<br><br>Sysadmins tend not to stick with (e.g.) the same MTA out of brand<br>loyalty or affection, per se, but rather just re-use what's worked for<br>them and whose configuration can be copied.  If I had to construct a new<br>Apache httpd + MTA + Mailman setup, I'd (more or less) replicate mine<br>because that's the path of least resistance:  You'd end up with a Debian<br>testing/unstable box with Exim4.x, the EximConfig add-ons, Mailman,<br>and Apache 1.3.x.  (I don't
 object to Apache2 as much as early in its <br>history, but it still strikes me as a textbook case of Second System<br>Effect.)<br><br>If I help you do something similar on an RHEL/CentOS box, I might at<br>points turn and stare blankly yet hopefully at _you_ on problems with<br>Apache2.x and with {sendmail|Postfix}.  If you're fine with that, I'm<br>fine with that.<br><br><br>There's one thing that Exim3/Exim4 does better (to the best of my<br>knowledge) than any other MTA: integration with Mailman.  Phil Hazel<br>(Exim author) coded a nice bit of "glue" where Exim can be configured to<br>read Mailman's list definitions directly.  When thus configured, Exim<br>need no special admin procedures to "see" new Mailman lists that you've<br>just created, and no special admin procedures to no longer "see" Mailman<br>lists you've just removed.<br><br>To my knowledge, no other MTA has that.  The config in question is<br>automatically present in Debian's packages; I don't know about
 other<br>distributions.  The fallback method for integration of Mailman with<br>MTAs, which when last I checked was still used by all non-Exim MTAs<br>and _might_ still be the default even with Exim on non-Debian distros,<br>is to add about half a dozen lines to /etc/aliases (and then re-run <br>"newaliases") upon creation of each new Mailman mailing list, to<br>intercept mail to each list-related address and hand it off to the <br>appropriate module of Mailman.<br><br>Debian strongly deprecates program-related lines in /etc/aliases for<br>security reasons (input validation), and to my knowledge you'd actually<br>have to go to some trouble to enable their processing (at least, in<br>Exim).<br><br><br>Anyhow, the _general_ nature of Mailman setup, phrased in a<br>distro-neutral manner, is like this:<br><br>1.  Do your general MTA setup.  Test, make sure it works OK.<br><br>2.  Do your general httpd setup.  Test, make sure it works OK.<br><br>3.  Install the Mailman package.
  Make sure you have a suitable<br>    Python runtime + libraries.  (Mailman is written in Python.)<br><br>4.  Configure your httpd to include the "plumbing" for Mailman's<br>    CGIs.  For my Apache 1.3.x setup, that's stuff like this in<br>    /etc/apache/httpd.conf:<br><br>    ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/<br>    Alias /pipermail/ /var/lib/mailman/archives/public/<br>    Alias /images/mailman/ /usr/share/images/mailman/<br><br>5.  Create the Mailman-internal mailing list called "mailman", <br>    which it uses for its internal records.  (This might happen<br>    automatically when you install the package.)  Customise <br>    mm_cfg.py if you need to.  (That's the main Mailman config<br>    file.)  Start Mailman's qrunner daemon.<br><br>6.  Create one or more real mailing list.  (I always start with<br>    one called "test".)   One does this with the script "newlist",<br>    which is in the "bin" subdirectory of the Mailman base <br>    directory.  About
 this time, you'll also need to figure<br>    out where the Mailman base directory is.  ;->  On my Debian<br>    boxen, it's /usr/lib/mailman.  All other Mailman stuff, <br>    including the Web archives (archives/private and archives/public)<br>    are within that base directory.<br><br>    When you run "newlist", e.g., "cd /usr/lib/mailman; <br>    bin/newlist test", newlist will do its job, and then advise <br>    you of the exact half-dozen lines it thinks you should add <br>    to /etc/aliases.  On my Exim4 system, I ignore those, because<br>    I know Exim4 automagically detects and handles Mailman list  <br>    addresses without help from the aliases file.  On a non-Exim<br>    or non-Debian system, you might need the aliases.<br><br>7.  Configure your new list(s) via the administrative Web screens, and<br>    then test them.  You're done!<br><br>The 50% that was non-facetious entailed (1) avoiding /etc/aliaseses<br>maintenance making your sysadminly life simpler,
 and (2) some other nice<br>defaults that keep the work minimal -- that in fairness _may_ be also<br>done by other distributions.<br><br>Big picture:  There's certainly nothing the Debian packages and their<br>defaults provide that a Scarlet Chapeau-style system can't.  If <br>_personally_ asked to handle all the niggling setup details, I'd<br>initially be at a disadvantage.<br><br>Mind you, the above is just the first, suspiciously easy step -- in a<br>way.  That is, great, you have a running system with running mailing<br>lists.  Now, what are you going to do about the spam problem?  Keeping<br>mailing lists, and systems in general, spam-free without working<br>yourself to death and without interfering with legitimate mail is a<br>seriously difficult problem.  And there are other sysadminly joys.<br><br><br>_______________________________________________<br>sf-lug mailing list<br>sf-lug@linuxmafia.com<br>http://linuxmafia.com/mailman/listinfo/sf-lug<br></blockquote><br>