|FROM ||Ruben Safir
|SUBJECT ||Re: [Hangout-NYLXS] events
|From hangout-bounces-at-nylxs.com Tue Oct 20 20:33:47 2015
Received: from www.mrbrklyn.com (www.mrbrklyn.com [126.96.36.199])
by mrbrklyn.com (Postfix) with ESMTP id 9764B1624E9;
Tue, 20 Oct 2015 20:33:45 -0400 (EDT)
Received: from [10.0.0.19] (stat13.mrbrklyn.com [10.0.0.19])
by mrbrklyn.com (Postfix) with ESMTP id 3F7A01624DE
for ; Tue, 20 Oct 2015 20:06:30 -0400 (EDT)
Date: Tue, 20 Oct 2015 20:06:30 -0400
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
Subject: Re: [Hangout-NYLXS] events
Reply-To: NYLXS Discussions List
List-Id: NYLXS Discussions List
Content-Type: text/plain; charset="us-ascii"
On 10/20/2015 07:40 PM, Rick Moen wrote:
> Quoting Ruben Safir (ruben-at-mrbrklyn.com):
>> So, if anyone didn't notice, the mailing had been down for a short
>> while. I was always proud of the fact that my highly hacking mailing
>> list solution which had majordomo in its center, was the only list I had
>> seen never to go down for any significant time and never needed to be
>> serivces. It just worked...
> That was the great thing about majordomo. Very simple to set up, and
> then it just ran.
>> It seems majordomo is dependent on a number of Perl4 components which
>> have been removed from the mainstram Perl distributions.
> A fix to the upstream code would have been more likely if Brent Chapman
> had ever fixed its no-commercial-use licence to make it open source, but
> he never did, so third-party coders chose to ignore it, and it's been a
> dead codebase since 2000. I'm not sure what the story is: It's
> possible that Brent lacked the authority to change its licensing terms
> by the time he realised the problem, having vested copyright title in
> Great Circle Associates, who in turn abandoned it.
> Anyway, yep, Perl5 and up breaks it completely.
>> Overall, mailman has some issues. It is too complex and the SuSE package seems to leave it as a mystery as to where things are located.
> Unless SUSE has done something very peculiar, you'll find highly useful
> command-line utilities in $MAILMAN_HOME/bin (where $MAILMAN_HOME, as
> noted below, is usually /var/lib/mailman).
> $ ls /var/lib/mailman/bin
> add_members convert.pyc invite_members postfix-to-mailman.py show_qfiles
> arch discard list_admins postfix-to-mailman.pyc sync_members
> b4b5-archfix dumpdb list_lists qmail-to-mailman.py transcheck
> change_pw export.py list_members qmail-to-mailman.pyc unshunt
> check_db export.pyc list_owners qrunner update
> check_perms find_member mailmanctl rb-archfix version
> cleanarch fix_url.py mmsitepass remove_members withlist
> clone_member fix_url.pyc newlist reset_pw.py
> config_list genaliases paths.py reset_pw.pyc
> convert.py inject paths.pyc rmlist
>> It uses a web admin interface which I despise....
> It also has the above-cited command-line interface, _and_ also a
> send-mail-to-the-MLM interface very reminiscent of majordomo's.
> I'm pretty sure all of the administrative functions can be carried out
> by mail instead of via the Web interface. For example, I have in front
> of me a held-mail message from the SVLUG Mailman instance, from one of
> the mailing lists' -request-at- addresses. Sure, it says up at the top:
> At your convenience, visit:
> to approve or deny the request.
> ...but it also says this at the bottom:
> Subject: confirm 361c754d16f24a21a13b1aac77cb181354cee04c
> Sender: svlug-request-at-lists.svlug.org
> From: svlug-request-at-lists.svlug.org
> If you reply to this message, keeping the Subject: header intact,
> Mailman will discard the held message. Do this if the message is
> spam. If you reply to this message and include an Approved: header
> with the list password in it, the message will be approved for posting
> to the list. The Approved: header can also appear in the first line
> of the body of the reply.
> You will want to Read The Fine Manual for further details.
>> ...and it makes it difficult to just pop open a
>> file in vim and add or remove things.
> There is indeed less use of plain-ASCII data files than with majordomo,
> which is occasionally irksome. Many of Mailman's internal records are
> kept in Python 'pickled' files, IIRC with '.pck' filename extensions.
>> The new list is slow... much slower than what majordomo did. Why?
> Do some basic troubleshooting to figure out where your specific
> performance bottleneck is (DNS, SMTP delivery from Postfix to Mailman,
> or Mailman), then tune it.
> Does the MTA/MLM box run its own local recursive nameserver and specify
> it in /etc/resolv.conf as the system's resolver? If not, I very
> _strongly_ recommend doing so. For that purpose, I also strongly
> recommend Unbound.
>> Maybe because it is not usung the OS level Unix Pipes? But that is a
> When you're done guessing, start diagnosing.
>> Overall, its security is less than it was with majordomo, IMO, because
>> of the complexity and its web based admin, which is rich but a PIA.
> If you don't want the Web-based admin, you can turn it off.
>> A Major problem here is that the configuration of mailman is spread
>> out all over the fucking hard drive in usr and var.
> No, it's really not (again, unless SUSE has done something very
> peculiar). Everything's under $MAILMAN_HOME, which is traditionally
> /var/lib/mailman -- though there are a couple of symlinks to things in
> /usr/lib/mailman and in /etc.
>> That means it is a PIA to make a backup or rebuild it need be.
> No, it's not. Here you go:
>> Instead of everything being in one nice location that I can just scoop
>> up, I have to find a dozen or so fragments.
> Copying and pasting from the above cheat-sheet:
> /etc System configuration files
> /var/lib/mailman/archives Mailing list archives for Mailman
> /var/lib/mailman/data Mailing list state and other data
> /var/lib/mailman/lists Mailing list definitions for Mailman
> /var/lib/mailman/nntp Mailing list NNTP gateway data
> /var/lib/mailman/qfiles Mailing list in-process data
> The /etc stuff is, unsurprisingly, in /etc/mailman. Here's the symlink
> to the key conffile therein:
> $ ls -al /usr/lib/mailman/Mailman/mm_cfg.py
> lrwxrwxrwx 1 root root 22 Aug 23 2010 /usr/lib/mailman/Mailman/mm_cfg.py -> /etc/mailman/mm_cfg.py
> And here are what I am pretty sure are most or all of the remaining
> $ ls -al /var/lib/mailman/
> total 15
> drwxrwsr-x 9 root list 1024 Aug 23 2010 .
> drwxr-xr-x 52 root root 1024 Oct 1 06:52 ..
> drwxrwsr-x 4 root list 1024 Jan 11 2012 archives
> lrwxrwxrwx 1 root root 20 Mar 4 2008 bin -> /usr/lib/mailman/bin
> lrwxrwxrwx 1 root root 24 Mar 4 2008 cgi-bin -> /usr/lib/cgi-bin/mailman
> lrwxrwxrwx 1 root root 21 Mar 4 2008 cron -> /usr/lib/mailman/cron
> drwxrwsr-x 2 root list 6144 Oct 20 12:15 data
> lrwxrwxrwx 1 root root 25 Mar 4 2008 icons -> /usr/share/images/mailman
> drwxrwsr-x 19 root list 1024 Jun 20 2011 lists
> lrwxrwxrwx 1 root root 17 Mar 4 2008 locks -> /var/lock/mailman
> lrwxrwxrwx 1 root root 16 Mar 4 2008 logs -> /var/log/mailman
> lrwxrwxrwx 1 root root 21 Mar 4 2008 mail -> /usr/lib/mailman/mail
> lrwxrwxrwx 1 root root 24 Mar 4 2008 Mailman -> /usr/lib/mailman/Mailman
> drwxrwsr-x 38 root list 1024 Aug 23 2010 messages
> drwxrwsr-x 2 list list 1024 Apr 3 2009 nntp
> drwxrwsr-x 12 list list 1024 Apr 3 2009 qfiles
> lrwxrwxrwx 1 root root 24 Mar 4 2008 scripts -> /usr/lib/mailman/scripts
> drwxrwsr-x 2 root list 1024 Feb 21 2008 spam
> lrwxrwxrwx 1 root root 12 Mar 4 2008 templates -> /etc/mailman
> -rw-r--r-- 1 root list 11 Jul 27 2010 .version
>> With means that the next step is rewriting my backup
> Well, yes, immediately after you say 'Thank you, Rick'.
thank you ... rick
hangout mailing list