Mailman 3 February 2000 - Mailman-Developers

Bug#57223: mailman: gate_news problems (fwd)
by Gergely Madarasz 08 Feb '00

08 Feb '00

Hello, Any ideas what might cause this ? ---------- Forwarded message ---------- Date: Mon, 07 Feb 2000 03:01:23 +0000 (UTC) From: Lazarus Long <lazarus(a)overdue.dhis.net> To: submit(a)bugs.debian.org Subject: Bug#57223: mailman: gate_news problems Resent-Date: Mon, 07 Feb 2000 03:03:28 +0000 (GMT) Resent-From: Lazarus Long <lazarus(a)overdue.dhis.net> Resent-To: debian-bugs-dist(a)lists.debian.org Resent-cc: Gergely Madarasz <gorgo(a)sztaki.hu> Package: mailman Version: 1.1-2 Severity: important Subject: Cron <list@phoenix> [ -x /usr/bin/python -a -f /usr/lib/mailman/cron/gate_news ] && /usr/bin/python +/usr/lib/mailman/cron/gate_news X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/var/list> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=list> Date: Mon, 7 Feb 2000 02:55:06 +0000 (UTC) Traceback (innermost last): File "/usr/lib/mailman/cron/gate_news", line 119, in ? main() File "/usr/lib/mailman/cron/gate_news", line 79, in main r,c,first,last,n = conn.group(mlist.linked_newsgroup) File "/usr/lib/python1.5/nntplib.py", line 208, in group resp = self.shortcmd('GROUP ' + name) File "/usr/lib/python1.5/nntplib.py", line 158, in shortcmd return self.getresp() File "/usr/lib/python1.5/nntplib.py", line 134, in getresp raise error_perm, resp nntplib.error_perm: 500 "GROUP" not implemented; try "help". -- System Information Debian Release: 2.2 Kernel Version: Linux phoenix 2.2.14 #1 Thu Jan 6 01:44:28 UTC 2000 i586 unknown Versions of the packages mailman depends on: ii apache 1.3.9-10 Versatile, high-performance HTTP server ii cron 3.0pl1-55 management of regular background processing ii libc6 2.1.2-13 GNU C Library: Shared libraries and Timezone data ii logrotate 3.2-11 Log rotation utility ii python-base 1.5.2-6 An interactive object-oriented scripting language. sendmail Not installed or no info ii postfix-tls 0.0.19991231pl02+0.51-1 A mail transport agent with RFC2487 encryption ^^^ (Provides virtual package mail-transport-agent) ii apache-ssl 1.3.9.10+1.37-1 Versatile, high-performance HTTP server with SSL support ^^^ (Provides virtual package httpd)

6 18

Re: [Mailman-Developers] race condition in locking ?
by Thomas Wouters 08 Feb '00

08 Feb '00

On Sat, Feb 05, 2000 at 08:56:53PM +0100, Ricardo Kustner wrote (in private): > Traceback (innermost last): > File "/usr/local/mailman/scripts/driver", line 112, in run_main > main() > File "../Mailman/Cgi/admindb.py", line 123, in main > mlist.Save() > File "/usr/local/mailman/Mailman/MailList.py", line 819, in Save > self.SaveRequestsDb() > File "../Mailman/ListAdmin.py", line 90, in SaveRequestsDb > self.__closedb() > File "../Mailman/ListAdmin.py", line 74, in __closedb > assert self.Locked() > AssertionError: > if you need to see the logs/error or logs/lock files let me know... [ CC: the list, because of the questions at the bottom ] Hmmm. I think I found the problem, but I'm not entirely sure. It looks like the default MailList lock timeout is 60 seconds, and that that is too short for your machine. You should see some 'stolen!' or (in my LockFile version) 'broken!' messages, in your logs/locks file. In any case, you can easily try it out; in Mailman/MailList.py, on or around line 282, there should be a 'lifetime = 60', inside the constructor for the maillists' lockfile. Changing the '60' in, say, '600', should give you better mileage, at least until your machine gets so heavily loaded that a simple admin request takes ten full minutes to process ;) I'm not sure what the Right Fix is, however. MailList.MailList does not have an advertised way of setting the lock lifetime, nor of refresh()ing the lock. Maybe someone with more experience (barry ? any other active developers) can shed light here... Is the usual solution to raise the initial lock timeout, passing lock timeout in the constructor, adding the two functions and calling them where appropriate, or just using __lock directly ? BTW, whoever documented that part of the code, thank you ;) with the 'TBD' remark above the lockfile constructor this was a sucker to find. It really means a lot to have it so well documented. -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 5

Re: [Mailman-Developers] Reply goes to list error
by Harald Meland 08 Feb '00

08 Feb '00

[Balazs Nagy] > On Tue, 18 Jan 2000, Balazs Nagy wrote: > > > Hi, > > > > I know that reply to the list address is obsolete and not supported but in > > my list there're a bunch of people who claim this feature. It worked in > > the last version but the CVS version doesn't use this option anymore. > > Here's the patch. > > I just cannot understand why nobody from thosw who have write access > did anything about the subject. Because Reply-To: munging is already part of CookHeaders.py, I guess. And that takes appropriate note of the "fastrack" attribute of the message object, too. -- Harald

2 1

Two more TODO entries
by Gerrit Holl 08 Feb '00

08 Feb '00

Hello, I have two TODO list entries: * I think a nice feature would be to set headers. You could set an option "setheader", "header" and "content", with a boolean option "override". I think it should be added to the TODO list. Maybe Barry (and others) think Reply-To sucks, but when it's not set it's certainly a nice feature to have it set. I've added this hack at my site: if not msg.get('Reply-To'): msg['Reply-To'] = mlist.GetListEmail() in Mailman.Handlers.Cookheaders.process Because currently *all* mailinglist use it. * A mail admin having an own page with all lists he is admin of, soe can approve messages and subscribsions from a single place. I'm wanting to contribute to the documentation. Has this ever been discussed yet? If not, I'm going to start with a document using the Linuxdoc DTD as soon as I understand all Mailman code (which'll take quite a long time, to be fair). regards, Gerrit. -- Homepage: http://www.nl.linux.org/~gerrit -----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com Version: 3.12 GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE? Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y -----END GEEK CODE BLOCK----- moc.edockeeg.www//:ptth

1 0

editing email addresses
by Ola Flygt 08 Feb '00

08 Feb '00

Hello At Växjö University we are using Mailman for a number of lists. We are now in the process of changing email addresses for a lot of users since we have a change in the organization. Is there a way to change all the users email addresses in the database instead of deleting and adding them again? Best Regards, Ola Flygt

1 0

Patch: raising exception when user can't change admin password
by Gerrit Holl 08 Feb '00

08 Feb '00

Hello, I'm not sure wheter this is the right place to send patches. I sent a patch to mailman-cabal but it didn't seem to be the right place. Redirect me if I'm wrong. This patch, to SecurityManager.py, raises the MMAuthenticationError if an unauthorized user tries to change the site admin password. Currently, you just het an IOError. I find the currently unused MMAuthenticationError more clear. regards, Gerrit. -- Homepage: http://www.nl.linux.org/~gerrit -----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com Version: 3.12 GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE? Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y -----END GEEK CODE BLOCK----- moc.edockeeg.www//:ptth

1 0

unsubscriptions requiring approval
by Thomas Wouters 08 Feb '00

08 Feb '00

Another minor patch adding what I need to mailman ;) I also noticed this on the jitterbug list, so I guess more people had wished or at least wondered for it ;P I'm posting it mostly to see if it generates comments, and for me to find a good excuse to sleep. It's functional, it works on my test-list, but some of it (most notably the english -- is there a good word for 'unsubscription request' ?) sucks. Adding this has been mostly an exercise to learn a bit about the Mailman insides, and to see how easily it can be done; fairly easily ;) Comments are welcome, including "d'oh, dont write that, i already wrote it !" The patchs misses the file 'templates/unsubauth.txt' by the way.. Just copy subauth.txt and change 'subscr' into 'unsubscr' ;P Sleepy-ly y'rs, -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

Re: [Mailman-Developers] race condition in locking ?
by Harald Meland 07 Feb '00

07 Feb '00

[Thomas Wouters] > Well, attached you'll find the first change, the cvs diff to LockFile.py. Sorry for not having been around here earlier, but: I've already been running a non-backwards LockFile.py in our Mailman installation here at uio.no for over a month. My current CVS checkout is available ("live" :) under <URL: http://www.uio.no/~hmeland/tmp/mailman-userdb/>, with <URL: http://www.uio.no/~hmeland/tmp/mailman-userdb/Mailman/LockFile.py> being of special interest in this discussion... > I kept the API the same with one teensy exception. With the new > locking scheme, it's not possible to 'steal' a lock, only to break > the lock and then enter the lock() cycle to try and grab it. Umm, I'm not sure that would go down very well with all of (current) Mailman, as it would mean you'd have to reload any data that might have changed on disk (marshals etc.) if someone else got the lock before you... I've been taking the approach that the parts of Mailman that actually call steal() have to know what they're doing (and grepping seemed to indicate that that was correct -- it's mostly used by forked-off children to steal locks held by the parent), and thus steal() is awfully blunt and just overwrites the current lock. > I've tested this locker quite heavily, mailbombing my listserver > with 100+ simultaneous messages to mailman-test (which generated > 100+ bounces sent back to mailman, because my bouncing email address > is still on the list) and it hasn't barfed yet ;) Looks good -- I implemented my version of this due to severe locking problems when our Mailman server nearly ran out of swap when various log mails started arriving in hordes just after midnight... Combined with the mm_cfg.EX_TEMPFAIL trick seen in <URL: http://www.uio.no/~hmeland/tmp/mailman-userdb/scripts/post> this has kept our Sun SPARCstation 20 with 160MB RAM running our ~3.500 lists quite smoothly for the last month. I'll try having a look at what differences there are in the two versions of this tomorrow. Cheers, -- Harald

2 1

Re: [Mailman-Developers] Feature suggestion
by Harald Meland 07 Feb '00

07 Feb '00

[Mats Wichmann] > At 01:55 PM 11/22/1999 -0000, Adrian Eyre wrote: > >> However, my idea is this. What if there was some sort of mechanism in > >> place that stored the file in a different type of archive, and instead > >> of mailing the file, it included a link to click on to pick up the file > >> instead. > > > >Good idea. Could it be generalised to allow all people on the mailing list > >to specify a maximum attachment size. All attachments below this are > >attached to the e-mail, and any larger are replaced with links. Or maybe > >as a total attachment size for each e-mail, rather than on an attachment > >by attachment basis. > > Sure seems like it would be a useful feature. I'm mostly stuck > on very slow lines, many times it's a long-distance call to get > that much. I'd like to be able to defer getting attachments - > pretty much ALL attachments - until I know at least I've got a > toll-free connection, even if it's a slow one. Maybe there's not > enough of us so "blessed" to be worth a change, though.... I can sympathize with the initial idea (replacing the attachment with a link for _all_ list members), but the "generalisation" I don't feel to good about. If individual list members are allowed to customize what parts of a list message they want, it means Mailman has to generate umpteen different versions of an incoming post, and pass the appropriate version on to the different sets of members. That would scale rather poorly... Of course, if anyone wants this bad enough to code it up, and makes it possible to turn off site-wide for admins so inclined, it might be included. As for the initial suggestion: First step would be to teach Mailman something about MIME messages, any takers are welcome :) -- Harald

1 0

Re: Mailman-Developers digest, Vol 1 #442 - 12 msgs
by Bill Bumgarner 07 Feb '00

07 Feb '00

Agreed. I wish I had the time to fully generalize the code though I'm quite happy to hear that others think this is a good idea! As it stands, it is relatively close-- the Rewrite.py module has been extended such that the resulting rewritten message contains instances of WebDAVAttachment that contain the eventual URL (archival and retrieval) for the attachment and the decoded raw data of the attachment. I made the decision to call it WebDAVAttachment to imply the context within which it was written. However, the actual implementation of that particular class has very little that is specific to WebDAV other than some of the URL names. In hindsight, I really should have not prefixed the retrieval URL with 'dav'-- it has nothing to do with DAV, even given the current implementation. The ToArchiver Handler could clearly use some generalization! Actually, the actual process() method is relatively general, but the do_dav() method should likely be broken out. Applying a bit more thought to this, it strikes me that what should likely happen is one of several things: - enabling/disabling different archival methods should be separated from the configuration of that individual archival method. Certain archival configuration optiosn-- like monthly/weekly/etc (which the WebDAV stuff currently ignores. I apologize for that-- more below)-- should be left in a sort of "global" configuration area assuming that it is appropriate to apply the same options to more than one archive "style". - individual or broken out screens for the individual archival methods - broken out mechanism that does the actual "splitting" of the archive into the appropriate paths. Regardless of whether it is a filesystem or URL based archival mechanism, you pretty much *always* have a "root" location below which the entire archive resides. The current implementation does not share any code between the pipermail archiver and the WebDAV archiver. Part of this was because it was indicated that the pipermail stuff needed to be largely revisited and partially because I simply didn't have time to do the generalization I wanted. --- Thomas: If you want to contribute to the effort prior to Barry's work integrating back into the core repository, I can take on the task of integrating your patches into my source. Let me know and I can make sure the latest sources are available to you via a more direct means than the occasional tarball. The changes that you indicated are certainly the correct direction for this codebase-- it would likely make Barry's life easier in doing the final to-repository integration if the code were a bit more refined. Ultimately, it is likely Barry's call-- I have a limited amount of time available now that this stuff works, but I would like to invest that time in ensuring that the codebase is moving as rapidly as possible into being a supported part of the existing Mailman infrastructure. -- Apologies: These extensions were actually done as a part of the development of a proprietary solution for a client of CodeFab's. Early in the specification phase, it become abundantly clear that leveraging Mailman would gain us a whole bunch of functionality for free. Of course, the challenge was then convincing the client that the requirement for releasing said changes back to the community was a small price compared to the gain in feature set. This proved surprisingly easy. The client is a very positive minded, forward thinking group of folks that definitely understand and believe in things like Open Source and Good Engineering Practices. (If anyone is interested in working for such an entity in the NYC area-- with obvious ties to the Python community-- please let me know and I can forward your contact information to the appropriate individuals. They are a "pre-IPO" "dot com" with excellent "potential valuation". Yadda.). Our initial approach was to try and hire someone from this community to do the work. Both because we wanted someone more familiar with the codebase than me (1.2 expiremental via cvs was my first real exposure) and because I really wanted to focus on other aspects of the project. That didn't happen and I ended up doing all the work. Fine by me, I *love* programming in Python-- especially when working with a cool sourcebase. However, it did mean that there was a lot of pressure on me to make the code work as quickly as possible and minimize the amount of effort put forth to making the end result as generic as it really should be. To give the client credit, they understand and authorized me spending a bunch of time to do a minimal amount of work towards a design and implementation that would be palatable to the community. While they don't have an infinite amount of time/money to throw at this, they definitely recognized that an implementation that would be accepted by the community as rapidly as possible would benefit them, as well. So; I apologize for the state of some of the code. It is not as clean or as elegant as I would normally consider acceptable. At the same time, the work has been done, the end result actually works, and it is definitely a solution to a problem that has been very much at the forefront of a lot of folk's administrative environments. And, of course, getting that initial implementation out the door is always half the battle... thanks, b.bum /* From: Thomas Wouters <thomas(a)xs4all.net> wrote */ On Fri, Feb 04, 2000 at 01:10:49PM -0500, Barry A. Warsaw wrote: > > >>>>> "BB" == Bill Bumgarner <bbum(a)codefab.com> writes: > BB> For the Mailman-decode-mime-file-via-webdav modifications, I > BB> have a relatively significant set of addtions and patches to > BB> Mailman. > I'd like to take a crack at integrating the i18n changes this > weekend. If that goes smoothly, your stuff is next on my list. /* * I'm curious about this... I've browsed through the decoding/webdav patches, * and it seems explicitly webdav. I understand that Bill needed webdav, and * has thus only worked on that, and I appreciate the effort (we might have * customers who want it, eventually ;) but I'm wondering if the patch can't be * split in two different elements; webdav archiving, and attachment-decoding, * and making them seperately configurable. * * I do not care about installing and configuring webdav at the moment, our * setup can't handle it yet, but the automatic decoding of whatever * word-document or powerpoint presentation our (sometimes) braindead managers * post to our internal all-employees mailinglists, and placing it simply as a * seperate file in the mailing list archive is a _very_ attractive idea. Not * just to me, the rest of the sysadmin departement went 'ooh' and 'ahhh' when * I told them about this development ;) (Which made me feel quite good, I must * add. I still feel I have to 'prove' python and mailman to them.) * * I have no problem with (re)writing that part of the code, of course, but I'd * prefer to wait until Bill's code is in the CVS tree (so that I know the * style/layout and general idea has been approved of ;) */

2 1