[Mailman-Developers] How to downgrade from mailman 2.1a2 ? and some of my problems

[Barry A. Warsaw]

>>>>> "GK" == Georg Koch <gorg@sun1.imbi.uni-freiburg.de> writes:

    GK> First question: is it possible to downgrade to some older
    GK> version if my problems continue? How do I do it?

I've never tried it, but I'm doubtful.  Loading a list's config.db
into a newer Mailman automatically upgrades the implied scheme in that
file, and there are no provisions for reverting the schema.

Anyone trying the 2.1 cvs should be aware that this is alpha code for
a reason!  I'm probably (soon) going to set up some semi-permanent
test lists to start solidifying the code base, even if it technically
remains alpha to avoid a feature freeze.  I don't recommend upgrading
on a production system.

    GK> And here some of my problems using mailman 2.1 a2

Ah, and now this is what I'm interested in!

    GK> - mimelib 0.3 installed into site-lib, therefore the cron jobs
    GK> (python -S) did not find it (my solution: delete the -S in the
    GK> crontab entries)

That will increase start up time, so we should figure out why its
necessary.  Look at the bottom of Defaults.py and you should see some
"path hacking" to get site-packages back on sys.path even if -S is
used.  That must not be working for you, and I'd like to figure out
why.

    GK> - mailman wanted libssl and libcrypto and did not find them in
    GK> /usr/local/lib (I added links to /lib)

Hmm, this is a mystery since Mailman doesn't make explicit use of
anything that should link against those libraries.  What version of
Python are you using, and how did you build it?  For example, I'm
using a stock Python 2.1 built from source, on a RH6.1-ish Linux
distro:

% ldd /usr/local/bin/python
	libpthread.so.0 => /lib/libpthread.so.0 (0x40018000)
	libdl.so.2 => /lib/libdl.so.2 (0x4002a000)
	libutil.so.1 => /lib/libutil.so.1 (0x4002d000)
	libm.so.6 => /lib/libm.so.6 (0x40030000)
	libc.so.6 => /lib/libc.so.6 (0x4004c000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

So nothing that's statically linked in ought to require those
libraries.  You'll need to check your Python's lib-dynload/*.so files
for other links (again, my stock install doesn't have any).

This one sounds like a Python problem.

    GK> - I got a message "Another qrunner is alread running" every minute!
    GK>   At first I commented the message out, but now I restart
    GK> qrunner with cron only one every hour.

I'm seriously thinking that we should get rid of the cron-based
qrunner even for the watchdog, since we now have qrunner running as a
daemon.  I think I'll write a start script that just wraps around
cron/qrunner (which I don't want to rename for bogus CVS reasons), but
that would be appropriate for an /etc/init.d script.

    GK> - some messages from check_db about invalid triple...(ignored)

Huh?

    GK> - After the first message came in for distribution, I was not
    GK> send out, but the program kept on adding new qrunner processes
    GK> until I killed them all . I then deleted the master-qrunner
    GK> entries in $MAILMAN/locks and all other locks. When I
    GK> restarted the qrunner, I did not get the expected master.lock
    GK> file again. I already got a 2,7MB error message.  But the mail
    GK> gets send.

Hmm, I'm not sure I totally follow, but let's try an experiment.
Remove the qrunner entry from crontab and just start the master
qrunner by hand at a shell prompt.  Don't give it any arguments.  Now
how well does it work?

    GK> - I had to find out first that all list passwords were
    GK> invalid, and then found the program to reset them :)

Yes, because MM2.0.x used crypt to encrypt the passwords, but MM2.1
uses sha since it's much more reliably built into Python.  This needs
to get prominent notice in the release notes because there is no
automatic way for Mailman to fix these passwords (the plain text
cannot be programmatically extracted).

    GK> - I found some files named *.msg and *.db in $MAILMAN/qfiles -
    GK> not in subdirectories. Is that ok?

No, these are left over from your pre-2.1 upgrade.  I haven't come up
with a good way to auto-upgrade these files, so I recommend that you
make sure your system is clear before upgrading.  You could try to
move them into qfiles/in and see what happens (cross your fingers).

    GK> MAIN Problem: - over the weekeend, the first round of password
    GK> reminders should have been out. But the disk ran full over the
    GK> weekend. I found the maschine with a load of 14, lots of
    GK> qrunners and some /bin/mails as well as the programs that
    GK> filled the disk (probably not mailman). I killed them all.
    GK> Later on I found 2 mail files (7 and 10 MB )in /var/tmp.
    GK> Where the passwords send out? At least 1 email, that had to be
    GK> approved, was not send: the administrator ran into an error
    GK> (file not found or something like that).  Can I trust
    GK> mailman2.1a2 that it is "disk full"-prove ?

I'm not sure why you ended up with those files in /var/tmp, as Mailman
shouldn't drop files there.  There could be some strange interactions
with your mailer going on.  I'll do some testing of the password
reminder scripts to make sure its working.

    GK> - right now I have 27 qrunners running - the master-qrunner is
    GK> held by one of them, but not the oldest one. It should be one
    GK> master and one per directory - right?

Yes, by default, although Mailman can be configured to run any number
of subprocesses per queue directory.  I strongly suspect a bad
interaction with the cron-based qrunner.  I don't think the cron entry
for qrunner is necessary any more, so again, I want to get rid of it.

    GK> - I made a new error log file. But there are already error
    GK> messages in it ( I only give the first and last lines:

    GK> Jul 02 10:14:30 2001 (1640) Uncaught runner exception: String
    GK> payload expected Jul 02 10:14:30 2001 (1640) Traceback (most
    GK> recent call last): [...]  Jul 02 11:37:15 2001 qrunner(2209):
    GK> raise TypeError, 'String payload expected' Jul 02 11:37:15
    GK> 2001 qrunner(2209): TypeError : String payload expected

This is saying that mimelib is having trouble generating the plain
text for one of your messages.  The latest CVS doesn't generate plain
text message until it has to send them to the MTA, otherwise, by
default it uses binary Python pickles since it can load and store them
to/from disk much faster.  I'll need to instrument Mailman so that
when these types of errors occur, the resulting objects can be
captures for post mortems.

Keep an eye on CVS over the next few days.
-Barry