|Re: [Hangout-NYLXS] events
> It seems majordomo is dependent on a number of Perl4 components which
> have been removed from the mainstram Perl distributions. Reverse
> engineering it was tried but ultimately it seems to be a losing
> proposition which go me deeper and deeper into custom hacks, so I finally
> abandoned it and we are no on mailman. 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. It uses a web admin interface which I
> despise and it makes it difficult to just pop open a file in vim and add
> or remove things.
There's good and bad with Mailman. I have many of the same complaints about
it that you've mentioned -- in particular I don't like that certain settings
are only in its Berkeley DB. On the positive side, Mailman has a lot of
Have a quick look at MLMMJ. ["Mailing List Manager Made Joyous"] I'm not
suggesting changing away from Mailman to it, rather just looking at it to
know that it exists as an alternative.
It's written in C and doesn't require a web interface to run it. There are
two web interfaces available for it; one in Perl and one in PHP. Last I
tried it the Perl web interface didn't work (the dependencies on the CentOS
package may not have been correct), but the PHP one does. MLMMJ doesn't
have a built-in web archive (because it doesn't have a web component to it
by default) but one can add one with Lurker or MHonArc. Between the two I'd
recommend MHonArc even though it's more complicated to configure, because
messages with UTF-8 Subject headers of today seem to get screwed up in Lurker.
With MLMMJ subscribed addresses are in plaintext files, headers to add (or
remove) are in plaintext files... and so on. All plaintext, all in one
place, easy to back up, as well as being easy to manually edit.
> The new list is slow... much slower than what majordomo did. Why? Maybe
> because it is not usung the OS level Unix Pipes? But that is a guess.
> 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.
This is true; there are a whole bunch of Mailman admin pages and things
aren't laid out like you'd expect.
> A Major problem here is that the configuration of mailman is spread out
> all over the fucking hard drive in usr and var. That means it is a PIA
> to make a backup or rebuild it need be. Instead of everything being in
> one nice location that I can just scoop up, I have to find a dozen or so
> fragments. With means that the next step is rewriting my backup
As you'll find out, exporting a list of subscribers requires digging into
the Berkeley DB manually too -- or using wget to dump admin web pages and
scraping them for subscribed addresses.
Congrats on getting the mailing list back up -- I have a good idea how much
work you just put into doing that.
hangout mailing list