Mailman-Developers June 1998

mailman-developers@python.org

14 participants
42 discussions

by Andrew Kuchling

I'm (finally!) revisiting the question of archiving for Mailman. There are two additional config parameters that seem to be needed. First, I need to know into what directory to write the formatted HTML files, both public and private. The private files shouldn't go into the actual Web tree, since they'll be accessed via the 'private' CGI script. Either there should be a parameter in mm_defaults/mm_cfg to specify the ARCHIVE_HTML_ROOT, or we could always write them into the Mailman tree somewhere -- say, ${prefix}/pipermail/html or /formatted or whatever. The second course would then require configuring the Web server to map your desired public archive URL to the root of the public tree, and the private archives to the CGI script. Second, I need to know what URL to use to access the public archives. (The private archives should be accessed via the 'private' CGI script.) Suggestions? -- A.M. Kuchling http://starship.skyport.net/crew/amk/ Seek those who find your road agreeable, your personality and mind stimulating, your philosophy acceptable, and your experience helpful. Let those who do not, seek their own kind. -- Henri Fabre

23 years, 3 months

Easing the burden of upgrades

by Barry A. Warsaw

We recently had an problem on python.org while upgrading to a new release of Mailman that started me thinking about a better way. I'll describe what I think is the problem, sketch out a proposed solution, and throw it out to y'all to discuss. Ken is as much responsible for the good ideas in this message as I am (blame me for the lousy ones); thanks to him for sitting down and thrashing this out first. The fundamental problem with a system like Mailman is that it is extremely difficult to test. The project is obviously not mature enough to have much of a test suite (if any), and writing one that tests all the interactions between MUA, MTA, Web browser, server, Python, and Mailman will be daunting to say the least. It'll be fantastic when we have even the framework for such a beast, but until then... So most of our testing involves creating and managing little toy lists, with us flogging the most noticeable features of Mailman to make sure the common stuff hasn't broken. The problem is that for sites using Mailman in an operational system, flag day (i.e. the day the upgrade to a new version occurs) can be pretty traumatic if we missed something crucial, but peculiar about a site. So I'm really concerned with how to make life less stressful for the operations folks who are relying on Mailman for their bread and butter. New features, fixes, etc. are strong incentive for those people to upgrade, but the fear of breakage (resulting in thousands of angry members) probably highly outweighs that incentive. Can we make the transition to a new version more controlled? You could go with a low tech approach of installing new versions temporarily with a different $prefix, using symbolic links to share list databases and templates, and hacking /etc/aliases as lists are converted to the new version. The one insurmountable problem that I see is the CGI URL. You can't share two different CGI bin dirs without exposing this to users through the list URLs. This is IMO, a showstopper; the most visible aspect of the system should be the most stable. Ken and I came up with the following architecture, and I'd like to see what y'all think: >From a site administrators point of view, every Mailman installation has two `parities': a current parity and a future parity. Every list is associated with one of these parities; at any stable point in time every list is under the current parity. The system itself is associated with a parity, also the current parity at stable time. Now a new release comes out and Mailman automatically installs into the future parity (more on this below). None of the lists are automatically switched though. The site admin can switch the parity of individual lists. Let's say there's a command called `upgrade'. So upgrade toylist would switch `toylist' to the future parity. The site admin could run with this for a while, and get all warm and fuzzy about the new release. He would then upgrade reallist1 and repeat the process. Let's say he's upgraded three of his thirty lists and now has a lot of confidence in the new version. He then does upgrade * This converts all the lists to the future parity. There's one more twist however: the "system" itself is still running on the current parity even though all the lists are running on the future parity. One more command commit-parity would now commit to the new release; the future parity becomes the current parity and the current parity becomes the future parity. Maybe this auto-upgrades any still current parity lists. Data such as the list databases and templates would live outside the installed parity source code subdirs (more below). If at any time before the commit-parity is run, the site admin gets cold feet, he can downgrade reallistx or downgrade * to return the list or lists to the current parity. Now, when Mailman is installed, it always installs to the future parity, BUT ONLY IF ALL THE LIST PARITIES AND THE SYSTEM PARITY ARE CURRENT. If it ever notices that some lists are set to the future parity, but the system is still at the current parity, Mailman refuses to install. There would probably be a command to view the parities for lists and the system. I think the implementation would not be that difficult. A single file containing the parity status for each list and the system would be about the only database you'd need. The installed tree would change a bit. You'd probably have two directories inside $prefix, one that contains the current parity code and one that contains the future parity code. The list databases would live outside these two trees, directly under $prefix. List specific templates would be moved out of the templates directory, into $prefix/lists. I'd love to get some feedback from people. Is this really a problem that needs to be solved? Does this proposal solve the problem in a useful way? Is the abstraction clear? Is this just total overkill? -Barry

23 years, 4 months

forwarded message from Dave Wolfe

by Barry A. Warsaw

Is anybody familiar with Wilma? How does it compare with Mailman? -Barry

23 years, 4 months

fun Pipermail stuff

by Corbett J. Klempay

I've resumed my attempts to get Pipermail working on my system with some stock data (Ken Manheimer hooked me up with some matrix-sig archives)...I was having some problems earlier with Pythong not being able to find the bsddb module (I asked Andrew about it)...turns out that Python distro I had was whack (it was 1.5.1-4, for reference; upgrading to -18 seems to have fixed it). So, after upgrading, I tried running...seemed to be doing ok...it was 500+ articles in and hit this: Processing article #508 into archives ['1996q1.matrix-sig'] Traceback (innermost last): File "pysig.py", line 310, in ? publicF.processUnixMailbox(file, PySIGArticle) File "/home/cklempay/src/pipermail/pipermail.py", line 366, in processUnixMailbox a=articleClass(m, self.sequence) # Create an article object File "pysig.py", line 71, in __init__ hypermail.Article.__init__(self, message, sequence, keepHeaders) File "/home/cklempay/src/pipermail/hypermail.py", line 39, in __init__ pipermail.Article.__init__(self, message, sequence, keepHeaders) File "/home/cklempay/src/pipermail/pipermail.py", line 95, in __init__ date=time.mktime(date)-tzoffset TypeError: number coercion failed [galtgulch]~/src/pysig > ls Anyone know what the story is with this? I'm too inexperienced/clueless for this to be obvious (if it is). ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "College: the fountains of knowledge, where everyone goes to drink." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 -------------------------------------------------------------------------------

23 years, 4 months

mailman and sendmail

by Gergely Madarasz

Hello! You might already know about this, but anyway... Sendmail 8.8.8 and 8.9.0 segfaults on queue run of mime digests made by mailman, if the remote host doesnt support 8bitmime. As I understood, it is a bug in the header detection while converting 8bit to 7bit. The result is that those who are at the beginning of the recepient list of the digest get the digest at every queue run, those who are later (after and including the first address that gets handled by a non-esmtp host) don't get it at all. I got a patch for sendmail, it seems to be working, it is also included in debian's sendmail.deb package, version 8.8.8-20. I expect that it will be included in the upstream source soon, but if anyone experiences such problems (i expect most lists run in are not 8bitmime ;)), i can send him the patch. Greg -- Madarasz Gergely gorgo(a)caesar.elte.hu gorgo(a)linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/

23 years, 4 months

Lost maillist messages thursday eve (6/18) to friday noon (6/19)

by Ken Manheimer

Some of you may have lost postings posted to one of the following maillists between last thursday (6/18) evening and friday (6/19) noon. Mailman-Developers (1 msg) Matrix-SIG (8 msgs) DB-SIG (3 msgs) Doc-SIG (4 msgs) Pythonmac-SIG (3 msgs) XML-SIG (1 msg) Trove-Dev (6 msgs) This happened accompanying an upgrade of our maillist software, mailman, due to an bad interaction between a new mailman feature and an anti-spam (anti-relay) mechanism applied to python.org's sendmail configuration. This problem did not show during testing because our test recipients were all local, and not subject to the anti-relay constraints. If you sent something to any of these lists during that time frame and never saw it show, you may want to resend. Archiving was not affected, so you should be able to find the messages in the maillist archives. People receiving the lists in digest format were not affected, since the delivery problem was fixed before the digest delivery time. My apologies for the disruption! Ken Manheimer klm(a)python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # <http://www.python.org/psa/>. #

23 years, 4 months

probems with mailman

by Gergely Madarasz

Hello! I've just found mailman and i like it wery much, it seems much nicer then any other mailing list server i've seen. Here are some problems I've found: I tried to convert a list with about 300 normal and 220 digested subscribers to mailman with convert_list. It always failed with something like fork: resource currently not available ... it tries to send too many mails at once. The second problem is: the mail wrapper accepts exactly one gid to be run as. This makes it difficult to package up mailman in a binary package, for example for debian linux. I'm a debian developer myself btw. The problem is that we have several MTA-s available in the distribution (sendmail, smail, exim, zmailer, and as a non-free addition, even qmail), and each can use different gids, and even one can be configured to use a gid other then the default. So it would be very nice if it could be configured to accept a gid from a set ... Greg -- Madarasz Gergely gorgo(a)caesar.elte.hu gorgo(a)linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/

23 years, 4 months

bsddb module

by Corbett J. Klempay

Anyone know where to get the bsddb module that Pipermail wants? I'm screwing with it, and it is giving me an error because it claims I don't have the bsddb module...but Robin Dunn's page refers to 'the bsddb module included with the Python distribution'. (saying that it corresponds to db 1.85, while the newest are 2.x). Anyone know what's the story here? My Python installation is just from the Andrich RPMs. Corbett

23 years, 4 months

one more problem

by Gergely Madarasz

When I'm on the membership management page, choose another chunk to view, and my admin cookie expires just then, the cgi asks me the password, and then returns me to the membership management page with chunk=something in the url, but the first chunk in the html. Greg -- Madarasz Gergely gorgo(a)caesar.elte.hu gorgo(a)linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/

23 years, 4 months

MM 1.0b4 port 25 connection conflicts w/anti-spam non relay measures

by Ken Manheimer

In trying out 1.0b4 on python.org i discovered a logistical conflict with the sendmail 8 anti-spam non-relaying mechanism - it *may* be due to a fault in my implementation of it, but i thought it's worth giving people a heads up. For those of you unfamiliar with it, it's a measure that tells sendmail to restrict the set of hosts from and to which it will accept mail relays. See http://www.sendmail.org/antispam.html for more info. It's something that public sites that handle mail should in good consience do - it reduces spammer's options for concealing their message origins. My problem was that mail delivered via mailman on my site to sites not explicitly specified as acceptable recipients (in the /etc/RelayTo file, i think) were being rejected. I would have thought that the mail appeared to originate at python.org, which is in the RelayTo and LocalIP files, and so would be accepted, but no go - and i don't see a way to wildcard the RelayTo to enable any recipients. I would not be surprised if i'm missing a fairly easy way to configure the setup to accept these messages, but i'm not sure, and don't have the time right now to investigate (i was supposed to go out of town, for the weekend, earlier today.) I disabled the anti-relay mechanism for the moment, but wanted to ask if anyone out there has experience with this, and suggestions for making the direct port 25 connection work without disabling the anti-relay measures. Ken

23 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers June 1998