Brad Knowles wrote:

On 12/31/07, Gruver, Sandi wrote:

...

How can I set up a new list that sends to multiple existing lists - but only sends one message to each person - even if the person is a member of multiple lists?

a. LSOFT calls this a "superlist"

b. Can "Mailman" do this?

Not directly, no. When all you have is the name of the list, you don't know who any of the subscribers are. Once you've handed the message off to the list (or sublist) itself, it knows who it's own subscribers are, but doesn't know who any of the other subscribers are for any of the other lists.

With some command-line tools to dump the complete set of all subscribers from the selected sublists, then do a "sort -u" on those addresses and then re-import those into another list, you could achieve the same results. But this is not automatic, and would depend on you regularly running some sort of a cron job.

Mailman 2.1.10 has a new 'sibling list' feature that enables setting up a list with no members and some siblings, the members of which will receive copies of a post to the first list without duplication. This is only one example of the use of sibling lists.

Sibling lists are a much more powerful concept than umbrella lists. The only drawback is the sibling list features don't work for digest members or digests, but for individual message recipients, you can do much more than with umbrella lists and avoid duplicate messages.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Sandi Gruver wrote:

It's not clear to me even after reading MM archive posts how to contain this filesystem - /var/lib/mailman/archives/private.

So I go in and manually gzip the <listname>.mbox/<listname>.mbox file, but that doesn't stop the growth.

No, and if I understand correctly, you now have a relatively useless <listname>.mbox/<listname>.mbox file containing a gzipped mbox with additional text appended to it.

Yesterday I read about not gzipping the <listname>/2009-December.txt files so turned that off in mailman's cron. But ...

104 lists on RedHat EL4 server.

Thank you for simple, clear ideas, I'm not a programmer nor much of a techie.

If you don't have enough storage to support your archives, perhaps you should either get more or turn archiving off.

The point of an archive is to archive messages. By its nature, it grows with time.

Now that you're not gzipping the periodic .txt files, you can do

rm /path/to/archives/private/*/*.txt.gz

to remove all the old, redundant gzipped files.

If you want to delete older messages from the pipermail archive, you can do something like, e.g.

rm -r /path/to/archives/private/*/1997* rm -r /path/to/archives/private/*/attachments/1997* rm -r /path/to/archives/private/*/database/1997*

This will remove all of 1997. The only problem is that the archive table of contents will still have links to those nonexistent pages.

Another method is to edit the /path/to/archives/private/<listname>.mbox/<listname>.mbox files and remove older messages from the beginning of the file leaving only the newer messages at the end, and then run Mailman's

bin/arch --wipe listname. This will leave a consistent archive, but it will renumber all the messages and break any saved links or links in archived messages to other archived messages.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 2/24/2010 3:27 PM, Sandi Gruver wrote:

So I go in and manually gzip the<listname>.mbox/<listname>.mbox file, but that doesn't stop the growth. Yesterday I read about not gzipping the<listname>/2009-December.txt files so turned that off in mailman's cron. But ...

The only way to stop an archive from growing is to stop archiving messages. You could, however, edit the archive mbox to remove old messages and regenerate the pages. Check out- http://wiki.list.org/pages/viewpage.action?pageId=4030681 and http://wiki.list.org/pages/viewpage.action?pageId=7602232

You could also move the archives to a bigger file system, but doesn't eliminate the problem, it just puts it off.

z!