Mailman 3 January 2002 - Mailman-Developers

Admin passwords lost after python upgrade
by Krischan Jodies 14 Jan '02

14 Jan '02

I just moved a mailman 2.0.7 installation from our old server (Python 1.5.2) to our new one (Python 2.1.1). The site and list passwords did not work after that. The site admin password was easy to recover but the list admin passwords were no fun (too much clicking in the web interface ;-). Before the change dumdb delivered entrys like this: 'password': 'ktm3d.CsIdg1' After manually changing the password (using the site-admin password) they looked like this: 'password': '\x79\x3d\xd2$>\xc1\x5f\x19M\xd6\x96\x07\xfa\xf1GH', I believe I already read something about this problem but can't find it now. I would suggest to warn people somewere in the distribution - I had no problem because I am also the list-admin of all lists, but it would be painful to recover many passwords you don't know (and even don't _want_ to know) because they owned by the list-admins. Thanks, Krischan

1 0

more 2.1a4+ stuff
by Ron Jarrell 14 Jan '02

14 Jan '02

Ok, amazingly, it seems to be largely working. Two pieces of brokenness and a bitch. (I'd track this farther but suddenly entirely new fish have landed in my frying pan, and I have to context switch...) First, the bitch: It's annoying as crap to have to edit out: To finish creating your mailing list, you must edit your /etc/aliases (or equivalent) file by adding the following lines, and possibly running the `newaliases' program: >From between each and every single alias that genaliases dumps! Brokenness - email to my test list has a List-Archive: /pipermail header in it... And this list echoes to my local test newsgroup, and I'm getting Jan 14 10:57:52 2002 (4653) (NNTPDirect) NNTP error for list "rontest": 441 437 No colon-space in "From jarrell(a)lennier.cc.vt.edu Mon Jan 14 10:57:48 2002 " header The error is correct, but the problem, obviously, is the unix from header should never have hit the nntp server...

1 0

INSTALL file...
by Ron Jarrell 14 Jan '02

14 Jan '02

Ok, so, after falling behind I'm now trying to upgrade to the current alpha on my test machine, preparatory to thinking about planning the early phases of starting to install it on my production server... First thing I noted - typo in the INSTALL file :-). Talks you through installing email-0.96, then you're supposed to verify that email.__version__ is 0.93 after you install it...

1 0

Thanks Everyone - First Big Mailing
by Marc Perkel 11 Jan '02

11 Jan '02

Thanks! Well - except for some significant glitches - our effector newsletter went out just fine last night. I want to than everyone who helped me out here. All I have to do today is tune the system so I don't overload it again. I had SMTP_MAX_RCPTS = 250 Then - using Exim I had remote_max_parallel = 100 I'm wondering what values I should set for these and in exim - should I set: queue_run_max = 30 ? I'm going to upgrade python to the latest and greatest. If I get the exim processes down I shouldn't overload the file handles - but - in the 2.4 kernel - how do I increase the number of open files? Marc Perkel /root EFF

5 4

-bounces becoming crazy, typo in bin/newlist (and bin/rmlist)
by Fil 11 Jan '02

11 Jan '02

1) I've just faced a huge problem: the listname-bounces address has become crazy, sending bounced messages to the list-admins, and issuing "You have been removed from list" messges to bouncers, then again, then again, in a loop that sent 4000 messages before I interrupted it by sending all -bounces information into /dev/null (latest CVS) 2) There's a small typo in newlist: a double-quote is missing at the end of the listname-admin line (the same happens with bin/rmlist) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mailman@miel:~$ bin/newlist test Enter the email of the person running the list: fil(a)rezo.net Initial test password: To finish creating your mailing list, you must edit your /etc/aliases (or equivalent) file by adding the following lines, and possibly running the ewaliases' program: ## test mailing list test: "|/home/mailman/mail/mailman post test" test-admin: "|/home/mailman/mail/mailman bounces test test-bounces: "|/home/mailman/mail/mailman bounces test" test-join: "|/home/mailman/mail/mailman join test" test-leave: "|/home/mailman/mail/mailman leave test" test-owner: "|/home/mailman/mail/mailman owner test" test-request: "|/home/mailman/mail/mailman request test" -- Fil

2 1

can't use mailmanctl -s start
by Fil 11 Jan '02

11 Jan '02

I don't know how to properly set up my system so that mailman restarts after a crash. I've just experienced one a few minutes ago, and here's the situation # /etc/init.d/mailman start Starting list server: mailman. The master qrunner lock could not be acquired. It appears as though there is a stale master qrunner lock. Try re-running mailmanctl with the -s flag. # /home/mailman/bin/mailmanctl -s start Starting Mailman's master qrunner. Traceback (most recent call last): File "/home/mailman/bin/mailmanctl", line 492, in ? main() File "/home/mailman/bin/mailmanctl", line 364, in main lock._transfer_to(pid) File "/home/mailman/Mailman/LockFile.py", line 357, in _transfer_to os.link(self.__lockfile, self.__tmpfname) OSError: [Errno 2] No such file or directory # ps aux | grep mailman mailman 924 0.0 0.3 4440 2968 pts/1 S 11:22 0:00 /usr/local/bin/python2.1 /home/mailman/bin/mailmanctl -s start So the process has failed but is still running? By the way, I've set things up so that : in mm_cfg.py: PIDFILE = '/var/run/mailman/mailman.pid' /var/run/mailman/ is emptied as startup (I've checked, it's empty now, and permissions seem to be correct: drwxr-xr-x 2 mailman mailman 4096 jan 9 11:15 /var/run/mailman/ I've got a /etc/init.d/mailman script that just does not much more than call /home/mailman/bin/mailmanctl start (Using the most recent CVS version, I prefer to post this to the -dev list) -- Fil

2 3

bin/update: "cannot import name SimpleCookie" in mailman cvs
by Marc MERLIN 11 Jan '02

11 Jan '02

So, when updating from 2.0 to cvs, make install ran fine up to update: Compiling /var/local/mailman/Mailman/pythonlib/StringIO.py ... Compiling /var/local/mailman/Mailman/pythonlib/__init__.py ... Compiling /var/local/mailman/Mailman/pythonlib/cgi.py ... Compiling /var/local/mailman/Mailman/pythonlib/mailbox.py ... Compiling /var/local/mailman/Mailman/pythonlib/rfc822.py ... Compiling /var/local/mailman/Mailman/versions.py ... Traceback (most recent call last): File "bin/update", line 47, in ? from Mailman import MailList File "/var/local/mailman/Mailman/MailList.py", line 58, in ? from Mailman.SecurityManager import SecurityManager File "/var/local/mailman/Mailman/SecurityManager.py", line 62, in ? from Cookie import SimpleCookie as Cookie ImportError: cannot import name SimpleCookie make: *** [update] Error 1 I have python 2.1.1 I move the lists off, completed the install, brought a list back, ran update by hand, and it worked. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f(a)merlins.org for PGP key

4 4

Mailman/Defaults.py is not updated?
by Fil 11 Jan '02

11 Jan '02

Bug in Mailman version 2.1a4+ We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/home/mailman/scripts/driver", line 86, in run_main main() File "/home/mailman/Mailman/Cgi/admindb.py", line 218, in main show_helds_overview(mlist, form) File "/home/mailman/Mailman/Cgi/admindb.py", line 390, in show_helds_overview (mm_cfg.ACCEPT, mm_cfg.HOLD, mm_cfg.REJECT, mm_cfg.DISCARD), AttributeError: 'Mailman.mm_cfg' module has no attribute 'ACCEPT' -- Fil

5 11

Re: [Mailman-Developers] First big Mailing
by J C Lawrence 11 Jan '02

11 Jan '02

On Thu, 10 Jan 2002 22:08:19 -0800 Marc Perkel <marc(a)perkel.com> wrote: > I'm doing my first big mailing with Mailman/Exim to deliver > effector for the Electronic Frontier Foundation. The list is about > 20,000 names. I'm going to do some guessing here, so make allowances. > Anyhow - started out moving right along, maybe too well - > saturated the T1 pretty quick and the system slowed down. But the > email logs were really going fast. This went on for about 45 > minutes. Translation: A message came in, was approved (automatically or by moderation) and moved to ~mailman/qfiles along with a copy of the the distribution list. qunner ran a little while later (cron job), and started delivering the broadcast to the MTA (thus all the activity). > During this time I saw a number of errors. Messages indicating the > I had too many files open (running tail on the exim logs). A few > messages that looked like something couldn't open something.db or > something like that. Not good. Very not good. Loose guess: You have configured Exim for more queue runners, parallel deliveries, and/or simultaneous incoming deliveries that Exim exceeded either your kernel's maximum number of file handles per process, or the total number of file handles in the system. You need to track this down and fix it. Now. Before you do anything else. It may be enough (for the short term) to just reconfigure Exim to use a smaller number of processes etc, but that's a stopgap, not a fix. > The delivery slowed down as it it were done. System load dropped > back to low normal levels. This sounds like qrunner processes being forked by cron, each trying to deliver more of your 20K messages to Exim. Qrunner has an internal timeout (15mins IIRC) after which it will be reaped and a new process forked by the next cron pass. > This lasted a while - then things started back up again really > delivering messages. These deliveries come in spurts. Which would explain the above bit. > Anyhow - even though Exim is delivering other email. Messages sent > to mailman are getting "stuck". Odds are good that a qrunner process was ungracefully reaped resulting in a stale lock file in ~mailman/locks. As a result subsequent qrunner processes are doing nothing, waiting for the lock to timeout. Fix: Check that there are no qrunner processes running. If so, delete ~mailman/locks/* Notes: You *REALLY* need to fix your file handle problem. Its not unlikely that that's is a fundamental cause of your problems. qrunner is responsible for all motion of mail thru the Mailman system, in receipt, moderation, and broadcasting. If qrunner is locked, nothing will happen until it is unlocked. > It's as if nothing in mailman is working. I see messages being > sent to mailman. But mailman isn't responding. Nope. They're being stashed in ~mailman/data, awaiting qrunner to Do The Right Thing (deliver to list, process as bounce, broadcast, etc. > I don't know if something is holding these messages and this is > waiting in some queue - or if Mailman has crashed and is eating > messages - or someing is corrupt or locked or overloaded or what. See above. Again: FIX YOUR FILE HANDLE PROBLEM FIRST! Until you do you can lose mail and have inexplicable impossible to debug problems. Notes: If you can spare the systems, the first thing you'll need to do is separate the MTA that is handling final delivery from your Mailman machine. Bounce processing can and will *really* screw with your efficiencies and load with lists of that size. Recommended architecture for scaling Mailman in your sort of situation is to have your Mailman system deliver all outbound mail to a smarthost (either via a smarthost rule on your MTA, or directly via SMTP config in Mailman). Ensure that the MXing for bounces will *NOT* go back to your smarthost, but will go directly to your Mailman system, This allows your smarthost to be tuned for what you need it to do: handle outbound deliveries efficiently, and allows your Mailman system to remain responsive (and under less load as there's no local overburdened MTA queue) for processing inbound bounces etc. Set SMTP_MAX_RCPTS in ~mailman/Mailman/mm_cfg.py to something reasonably large. Suggest something in the 50 - 100 range. Do not go any larger. This may help with temporarily resolving your file handle problem. It will also decrease system load in general and help smooth things along a bit. Later, when everything is known working, you can start tuning for performance and look at dropping SMTP_MAX_RCPTS down to around 5 (usually the sweet spot). > Anyhow - I'd like some general feedback on what might be > happening. The newsletter contains an important story about Norway > inditing Jon Johansen criminally. He's the guy who wrote the DVD > code. Yeah, I read it. ObOffer: If you would like some help offloading your mail traffic, I'm willing to smarthost a chunk of it for you (will need to verify with my upstreams). Basic idea would be to smarthost route a couple TLDs to me for final delivery (I've got a couple T3's so I should be able to take a fair percentage of your load). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

First Big mailing
by Marc Perkel 11 Jan '02

11 Jan '02

I rebooted the system. Still have problems. > Well, you can double check and see if there are any stale lock files > in the locks directory. If you're exhausting your system resources as > Chuq points out, and your Python processes are either hanging, > thrashing with other processes, or just getting waxed by your kernel, > the processes holding the locks will fail hard, leaving stale locks > around. Yea - 28 files in the locks directory. Do I delete the locks? Thanks for your help. I'll fix it in the morning.

2 1