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 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<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>