[Mailman-Users] Multiple/Redundant Mailman servers
What's the Best Current Practice for running Multiple or Redundant Mailman servers? I have a distributed mail system - centralized local message store, and many SMTP/POP heads. I'd *like* to be able to run Mailman on all of them, with the same lists and configs. Currently I NFS mount the configs for many other software packages, and it works well. I've tried NFS mounting /usr/local/mailman, and making qfiles a symlink to a local directory on each machine. This doesn't work; I get messages shunted because of Stale NFS filehandles and permission errors, even though check_perms says I'm good. If this simply isn't possible, I can shunt all of the mail to a central list server, and just back-up mailman so I can bring it up elsewhere if necessary. But I'd love to have a way to do this. -- Charlie Watts Brainstorm Internet 970 247-1442 x113 [EMAIL PROTECTED] http://www.brainstorminternet.net/ -- Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ This message was sent to: [EMAIL PROTECTED] Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] locks, max cpu, postfix, qrunner ugliness
On Sun, 17 Feb 2002, Morgan Fletcher wrote: Charlie Watts [EMAIL PROTECTED] writes: Anyway, I'd ktrace/strace that python instance, see what it's doing. And look in your mail logs - is it actively dumping things into postfix, or has it not even gotten there, or has it started and paused? Is python just sitting there busy-waiting? I 'ktrace -dp pid', waited five minutes, did 'ktrace -c', then 'kdump | less'. snip ktrace output with qrunner busy-waiting Try taking qrunner out of cron, sending a message to the list, and starting qrunner under ktrace. Then do the 'kdump | less' and you should be able to see where it changes to busy-waiting ... Is it a lock issue? I also should mention that I tested this mailman installation for about a month with a small list (~30 addresses) with no problems, and for about a week with a larger list (~400 addresses), also with no problems. Both those lists contained valid addresses. We did test subscribing an address to the second list, then removing the user that was subscribed at the user's host, and mailman successfully unsubscribed it after it bounced for a while. Now the 1800-member list is generating a ton of bounces, and I have a feeling that's what's choking qrunner. But I may have been biased by reading this: http://sourceforge.net/tracker/?group_id=103atid=100103func=detailaid=449550 Probably not quite the same - in that, qrunner is -dying-. Yours is just spinning its wheels. Hrm. I've got 11k users in a list, and know of folks with 100k user lists. -- Charlie Watts [EMAIL PROTECTED] Frontier Internet, Inc. http://www.frontier.net/ -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] locks, max cpu, postfix, qrunner ugliness
On Sun, 17 Feb 2002, Morgan Fletcher wrote: Morgan Fletcher [EMAIL PROTECTED] writes: I just used bin/add_members to build out the ~1800 members of our mailing list. Now, python (2.0) is wedging itself everytime it's launched: PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND 4246 mailman 57024M 23M run 8:22 98.44% 98.44% python I meant to write that qrunner is wedging itself. I'm running Mailman 2.0.8 on Python 2.0, NetBSD 1.5.1, Postfix-20010228-pl03, machine is beefy. I think our list is hitting some sort of postfix limitation, but I'm not sure what it is. Why do you think it's postfix? That doesn't make sense, based on what you've said. Anyway, I'd ktrace/strace that python instance, see what it's doing. And look in your mail logs - is it actively dumping things into postfix, or has it not even gotten there, or has it started and paused? Is python just sitting there busy-waiting? -- Charlie Watts [EMAIL PROTECTED] Frontier Internet, Inc. http://www.frontier.net/ -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Problems with undeliverable mail
On Sat, 29 Dec 2001, Michelle Brownsworth wrote: On Thu, 27 Dec 2001 14:06:53 -0800 Michelle Brownsworth [EMAIL PROTECTED] wrote: My mailhost is chugging away, trying over and over to deliver to a large batch of addresses with a .gov domain that doesn't resolve; this particular .gov nameserver is obviously having problems. And it's not from the sendmail's mail queue; /var/spool/mqueue/ is completely empty. It's Mailman reattempting to send to the problem addresses. Configure your MTA to not do DNS verifies on deliveries from localhost. But since none of the subscribers are local, I don't see how that will help in this situation. And as I said, the batch of reattempts didn't seem to be coming from sendmail's mail queue. The only explanation is that Mailman must have a means of keeping track of failed deliveries. Perhaps a re-phrasing: configure your MTA to blindly accept mail from localhost without verifying that the *destination* domain is valid. Many MTA configurations won't accept mail that they know they can't deliver - if the destination domain doesn't resolve, there's no point in accepting it. So the MTA reports, typically, a temporary SMTP error. Sounds like Mailman is trying, over and over, to get these messages into the MTA. If you instead configure your MTA to accept the message, it will accept it and immediately generate a bounce. Mailman does the right thing with bounces. Here's an example: my list of SMTPD restrictions from postfix. I reject mail for unknown recipient domains - but I have an exception list for my list servers. /etc/postfix/class_host_exception includes localhost and a few other machines that I let dump blindly into the system. smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/class_host_exception, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, reject_unauth_destination, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_invalid_hostname, permit This can also speed up injection into the MTA, if that's important to you. -- Charlie Watts [EMAIL PROTECTED] Frontier Internet http://www.frontier.net/ -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Big Lists
On Mon, 17 Dec 2001, Bill Moseley wrote: Someone posted a few days or so ago asking about list sizes. Was there any response to that query? I've got a list of about 11,000 currently on Solaris/Sendmail/listproc that I'm thinking of moving to Linux/(qmail|Postfix)/mailman. Only one message a week is sent. Anyone running a list that big on Mailman? Any special setup required? Sure, one of my lists is that big. Nothing fancy required. If you want it to go fast, make sure your mail server if set up to handle whatever sort of volume you are looking for. I think some folks here have -much- bigger lists ... -- Charlie Watts [EMAIL PROTECTED] Frontier Internet, Inc. http://www.frontier.net/ -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Users] Slow command-line unsubscription
On Sat, 14 Jul 2001, J C Lawrence wrote: On Fri, 13 Jul 2001 22:56:13 -0700 Chuq Von Rospach [EMAIL PROTECTED] wrote: On 7/13/01 3:43 PM, Charlie Watts [EMAIL PROTECTED] wrote: I'm trying to unsubscribe about 1000 addresses from a list of about 12,000. It is taking -forever- . Watching ~logs/subscribe, addresses are being un-subscribed at about 1 message per second. Is this normal? Wouldn't surprise me. Since it's a single process, your MP machine isn't going to use all it's CPU, but the operation is going to be primarily disk-limted anyway -- are you using fast disks? Slow disks? According to brief examination here its lock bound rather than IO or CPU. Thank you both. Chuq - yes, fairly fast disks, but even really slow disks should be able to change a (small) file faster than that. The lock-bound explanation makes complete sense. It wasn't so much a -problem- that it took a long time, as that it seemed potentially broken, and I wanted to check. -- Charlie Watts [EMAIL PROTECTED]Frontier Internet Systems Janitor and Network Plumber http://www.frontier.net/ -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
[Mailman-Users] Slow command-line unsubscription
I'm trying to unsubscribe about 1000 addresses from a list of about 12,000. This is on FreeBSD 4.3, a dual-proc PIII 500. Otherwise un-loaded. Command-line: ~/bin/remove_members -f /tmp/un-newsletter newsletter It is taking -forever- . Watching ~logs/subscribe, addresses are being un-subscribed at about 1 message per second. Is this normal? -- Charlie Watts [EMAIL PROTECTED]Frontier Internet Systems Janitor and Network Plumber http://www.frontier.net/ -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
[Mailman-Users] Re: Archiving problems ...
On Fri, 18 May 2001, Charlie Watts wrote: I've got mailman 2.0.5 installed on a FreeBSD4.3-stable system. The administrative and user E-mail and web interfaces are working superbly. E-mails to the list go out promptly and smoothly. But I can't get it to archive anything to save my life. It doesn't seem to so much as -touch- the filesystem. Well, I don't think I'm a -total- idiot anymore, but I'm still confounded. I cvsupped rebuilt the world, and everything is working. Apologies for wasting your time ... -- Charlie Watts [EMAIL PROTECTED]Frontier Internet Systems Janitor and Network Plumber http://www.frontier.net/ -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
