From scott@chronis.icgroup.com Fri Oct 2 17:43:17 1998 From: scott@chronis.icgroup.com (Scott) Date: Fri, 2 Oct 1998 12:43:17 -0400 Subject: [Mailman-Developers] duplicates not linux specific Message-ID: <19981002124317.28980@chronis.icgroup.com> I just set up a mailman installation on Solaris 2.5.1. A list owner reported duplicate deliveries, so I made the quick and dirty change to the "deliver" script so that it won't fork any more. just thought I'd mention that the problem may not be linux-specific. scott From scott@chronis.icgroup.com Fri Oct 2 20:55:30 1998 From: scott@chronis.icgroup.com (Scott) Date: Fri, 2 Oct 1998 15:55:30 -0400 Subject: [Mailman-Developers] (long) queue problems: an analysis Message-ID: <19981002155530.51447@chronis.icgroup.com> the mailman outgoing mail queue has a number of concurrency-control issues. here's an overview of the processes involved in the queue, from what I can tell so far: 1) before a delivery is attempted, the message is queued. This is a good idea because if there is an unforeseen exception that kills the delivery process, we want the data already on disk so that it can be delivered at a later time. 2) each time a delivery is requested via the contact_transport script, the entire mail queue is rerun. 3) when there are subscribers that belong belong to more than one domain, there are potentially multiple contact_transport processes running concurrently per post as per the forking in the deliver script. anytime there is more than one contact_transport script being run, there is the possibility that one of those processes is in the middle of delivering a message (that's already been queued and not yet dequeued) while another one reads that queue entry and assumes that since it's in the queue, it needs to be delivered and attempts to do the delivery. while both probably deliver the same message (producing duplicates) whichever of the two processes finishes the delivery first unliks the file, and the remaining one fails to do so creating exceptions in logs/errors like this: Oct 02 12:01:23 1998 contact_transport: Traceback (innermost last): contact_transport: File "/home/mailman/scripts/contact_transport", line 60, in ? contact_transport: OutgoingQueue.processQueue() contact_transport: File "/home/mailman/Mailman/OutgoingQueue.py",line 38, in processQueue contact_transport: Utils.TrySMTPDelivery(recip,sender,text,full_fname) contact_transport: File "/home/mailman/Mailman/Utils.py", line 226,in TrySMTPDelivery contact_transport: OutgoingQueue.dequeueMessage(queue_entry) contact_transport: File "/home/mailman/Mailman/OutgoingQueue.py",line 25, in dequeueMessage contact_transport: os.unlink(msg) contact_transport: os . error : (2, 'No such file or directory') the same problem can occur when a run_queue process runs concurrently with another run_queue process or a contact_transport process and produces the same traceback from a different top level: Oct 02 09:10:16 1998 smtplib: Traceback (innermost last): smtplib: File "/home/mailman/cron/run_queue", line 31, in ? smtplib: OutgoingQueue.processQueue() smtplib: File "/home/mailman/Mailman/OutgoingQueue.py", line 38, in processQueue smtplib: Utils.TrySMTPDelivery(recip,sender,text,full_fname) smtplib: File "/home/mailman/Mailman/Utils.py", line 226, in TrySMTPDelivery smtplib: OutgoingQueue.dequeueMessage(queue_entry) smtplib: File "/home/mailman/Mailman/OutgoingQueue.py", line 25, in dequeueMessage smtplib: os.unlink(msg) smtplib: os . error : (2, 'No such file or directory') In addition to this, there are permissions problems that can arise: when a contact_transport script is called, it is called from the mail process, and is set with group id mailman and whatever userid the calling process hands to it. it creates a queue file whose owner is the uid of the process. later, when run queue is run, it is run with mailman's uid and consequently cannot do may things to the queue file, like unlink it. If the file isn't written with group read permissions, it can't read it either, and you get tracebacks like this: Oct 02 12:50:03 1998 smtplib: Traceback (innermost last): smtplib: File "/home/mailman/cron/run_queue", line 31, in ? smtplib: OutgoingQueue.processQueue() smtplib: File "/home/mailman/Mailman/OutgoingQueue.py", line 34, in processQueue smtplib: f = open(full_fname,"r") smtplib: IOError : (13, 'Permission denied') So we need a mail queuing architecture that will address all these issues. scott From scott@chronis.icgroup.com Fri Oct 2 23:22:27 1998 From: scott@chronis.icgroup.com (Scott) Date: Fri, 2 Oct 1998 18:22:27 -0400 Subject: [Mailman-Developers] (long) queue problems: an analysis In-Reply-To: <19981002155530.51447@chronis.icgroup.com>; from Scott on Fri, Oct 02, 1998 at 03:55:30PM -0400 References: <19981002155530.51447@chronis.icgroup.com> Message-ID: <19981002182227.03943@chronis.icgroup.com> On Fri, Oct 02, 1998 at 03:55:30PM -0400, Scott wrote: | the mailman outgoing mail queue has a number of concurrency-control issues. [see previous post] | So we need a mail queuing architecture that will address all these | issues. Here's an idea: 1) we alter contact_transport so that it does not try to process the queue anymore. it would only deal with the delivery at hand. 2) we create a 2-part mailqueue inside mm_cfg.DATA_DIR/mqueue/{active,deferred}. when we enqueue a message for delivery, we put it in mqueue/active/. If the delivery succeeds, we unlink the file. If it fails, we rename the file to mqueue/deferred/. All mail queue files in active/ will be handled by a single process under the current delivery mechanism, so no concurrency control is necessary for active/ queue files. this would involve changes to TrySMPTDelivery, and the installation procedure. 3) we alter OutGoingQueue.enqueueMessage so that it can handle coming up with unique filenames under this 2-part mail queue mechanism. 4) we alter OutGoingQueue.processQueue so that it creates a site-wide queue_run lock file to prevent more than one queue run from happening at a time. this process will also check the active/ queue files for files whose modification/creation time is older than some configurable amount of time (on the order of 1hr-1day). For each of these files, it will rename them to the deferred/ part of the queue before proceeding to process them. These 'stale' queue files would only come about as a result of system crashes or memory errors or similar serious system related and unpredictable errors that can happen in the middle of an smtp transaction. the above scheme works in theory only when run_queue uid is the owner of all the queue files and/or root. I believe that it is possible for queue files to be owned by both the uid of the cgi and the uid of the local mail delivery agent. If this is the case, then either run_queue will have to be run as root, or all processes creating a queue file will have to setuid mailman before creating the file. Are there any preferences on which of these two approaches would be best? the above scheme should not effect delivery rates much at all, since the TrySMTP process would be the same except that it would have to add a rename() operation if delivery failed. There would be no contention over locks for most deliveries. deliveries that are deferred would be handled in a sequential manner, but even that should be ok since each message in the queue can have up to some very large number of recipients. (on an unrelated note - has anyone bumped up against rcpt limits with mailers yet?) if there aren't any concerns over this approach, i'll go ahead and code it -- starting monday. should take a day or two to code and test. scott From klm@python.org Sat Oct 3 02:43:37 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 2 Oct 1998 21:43:37 -0400 (EDT) Subject: [Mailman-Developers] (long) queue problems: an analysis In-Reply-To: <19981002182227.03943@chronis.icgroup.com> Message-ID: Scott, from what i know of the queue mechanism and error notices, i think your assessment of the situation is a good one (and a wise move, to take a comprehensive look at what's going on). I think one thing that _might_ alleviate some of the difficulty concerns the permissions issue. I know that in many unices you can use setgid directories to ensure that files created in the dir inherit the group id of the directory. By setting the group id appropriately to that of the process that will be servicing stuff left on the queue, and making sure that the processes putting stuff in the queue have group permissions enabled, then the queue servicing process has access if the placing process fail to do the send, and the placing processes have access by virtue of owning the files. I've used this setgid directory mechanism for many things with very good results - my only uncertainty is whether this behavior - that a setgid directory forces files created in the directory to assume the same group ownership as that of the directory - is common across all unices. Anybody know of prevalent contemporary unix systems where it doesn't hold? Ken klm@python.org From scott@chronis.pobox.com Mon Oct 5 20:13:21 1998 From: scott@chronis.pobox.com (Scott) Date: Mon, 5 Oct 1998 15:13:21 -0400 Subject: [Mailman-Developers] (long) queue problems: an analysis In-Reply-To: <19981002182227.03943@chronis.icgroup.com>; from Scott on Fri, Oct 02, 1998 at 06:22:27PM -0400 References: <19981002155530.51447@chronis.icgroup.com> <19981002182227.03943@chronis.icgroup.com> Message-ID: <19981005151321.19559@chronis.icgroup.com> i have coded the changes to the queueing mechanism, and checked in the relevant files (contact_transport, Mailman/Utils.py, and Mailman/OutgoingQueue.py) to the cvs tree. Just wanted to note a couple of things that differ slightly between what i coded and the plan below: 1) a closer look at the code prompted me to use file metadata to denote whether a q entry has been deferred because it allowed the conveniance of continueing to use the tempfile module. Origonally, i tried setting the sticky bit on files that are in an active state, and found that on some OS's in some conditions it wouldn't let certain users set this, so i decided to use the setuid bit instead. 2) as per Ken's suggestion, the setgid data directory would work in conjuntion with some chmod'ing of the q entries. there's no need to muck with what programs get set{u,g}id to what as far as i can tell. scott On Fri, Oct 02, 1998 at 06:22:27PM -0400, Scott wrote: | On Fri, Oct 02, 1998 at 03:55:30PM -0400, Scott wrote: | | the mailman outgoing mail queue has a number of concurrency-control issues. | | [see previous post] | | | So we need a mail queuing architecture that will address all these | | issues. | | Here's an idea: | | 1) we alter contact_transport so that it does not try to process the | queue anymore. it would only deal with the delivery at hand. | | 2) we create a 2-part mailqueue inside | mm_cfg.DATA_DIR/mqueue/{active,deferred}. when we enqueue a | message for delivery, we put it in mqueue/active/. If | the delivery succeeds, we unlink the file. If it fails, we rename | the file to mqueue/deferred/. All mail queue files in | active/ will be handled by a single process under the current | delivery mechanism, so no concurrency control is necessary for | active/ queue files. this would involve changes to TrySMPTDelivery, | and the installation procedure. | | 3) we alter OutGoingQueue.enqueueMessage so that it can handle coming | up with unique filenames under this 2-part mail queue mechanism. | | 4) we alter OutGoingQueue.processQueue so that it creates a site-wide | queue_run lock file to prevent more than one queue run from | happening at a time. this process will also check the active/ | queue files for files whose modification/creation time is older | than some configurable amount of time (on the order of 1hr-1day). | For each of these files, it will rename them to the deferred/ part | of the queue before proceeding to process them. These 'stale' | queue files would only come about as a result of system crashes or | memory errors or similar serious system related and unpredictable | errors that can happen in the middle of an smtp transaction. | | the above scheme works in theory only when run_queue uid is the owner | of all the queue files and/or root. I believe that it is possible for | queue files to be owned by both the uid of the cgi and the uid of the | local mail delivery agent. If this is the case, then either run_queue | will have to be run as root, or all processes creating a queue file | will have to setuid mailman before creating the file. Are there any | preferences on which of these two approaches would be best? | | the above scheme should not effect delivery rates much at all, since | the TrySMTP process would be the same except that it would have to add | a rename() operation if delivery failed. There would be no contention | over locks for most deliveries. deliveries that are deferred would be | handled in a sequential manner, but even that should be ok since each | message in the queue can have up to some very large number of | recipients. (on an unrelated note - has anyone bumped up against rcpt | limits with mailers yet?) | | if there aren't any concerns over this approach, i'll go ahead and | code it -- starting monday. should take a day or two to code and | test. | | scott | | | | | | _______________________________________________ | Mailman-Developers maillist - Mailman-Developers@python.org | http://www.python.org/mailman/listinfo/mailman-developers | From scott@chronis.pobox.com Mon Oct 5 21:13:12 1998 From: scott@chronis.pobox.com (Scott) Date: Mon, 5 Oct 1998 16:13:12 -0400 Subject: [Mailman-Developers] web archiving Message-ID: <19981005161312.40765@chronis.icgroup.com> did i see that someone had posted a patch to include functional pipermail web archiving to mailman? if there are any, please let me know where to find it again. scott From The Dragon De Monsyne Tue Oct 6 02:49:38 1998 From: The Dragon De Monsyne (The Dragon De Monsyne) Date: Mon, 5 Oct 1998 20:49:38 -0500 (CDT) Subject: [Mailman-Developers] web archiving In-Reply-To: <19981005161312.40765@chronis.icgroup.com> Message-ID: On Mon, 5 Oct 1998, Scott wrote: > did i see that someone had posted a patch to include functional > pipermail web archiving to mailman? if there are any, please let me > know where to find it again. Yup. I did, on Thu, 27 Aug 1998 01:48:58 -0500 (CDT) It should be in the archives for the list. If ye want I can fwd you a copy. -The Dragon De Monsyne From bavo@ace.ulyssis.student.kuleuven.ac.be Tue Oct 6 18:23:58 1998 From: bavo@ace.ulyssis.student.kuleuven.ac.be (Bavo De Ridder) Date: Tue, 6 Oct 1998 19:23:58 +0200 (CEST) Subject: [Mailman-Developers] CVS / Queuing problem Message-ID: Hello, I run a site with the mailman listmanager. I run several lists (10-15). I recently encountered the problem with the duplicates. For my site this is not only annoying but also inacceptable! I read in the archives that Scott has checked in some changes to the CVS to adres this problem (the files contact_transport, Mailman/Utils.py, Mailman/OutgoingQueue.py). This was on October 6. Can I access the CVS to get these files? Will it address my problem? Is there anyone to send me those (updated files), if I can't get at the CVS? Thanks Bavo De Ridder From klm@python.org Tue Oct 6 18:31:14 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 6 Oct 1998 13:31:14 -0400 (EDT) Subject: [Mailman-Developers] CVS / Queuing problem In-Reply-To: Message-ID: On Tue, 6 Oct 1998, Bavo De Ridder wrote: > I run a site with the mailman listmanager. I run several lists (10-15). > I recently encountered the problem with the duplicates. For my site this > is not only annoying but also inacceptable! > > I read in the archives that Scott has checked in some changes to the CVS > to adres this problem (the files contact_transport, Mailman/Utils.py, > Mailman/OutgoingQueue.py). This was on October 6. (Yay scott, btw!! I'm looking forward to hearing about results from exercising the revisions...) > Can I access the CVS to get these files? Will it address my problem? Is > there anyone to send me those (updated files), if I can't get at the CVS? Visit http://www.python.org/mailman/listinfo/mailman-checkins - it has instructions. Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # From scott@chronis.pobox.com Tue Oct 6 18:59:31 1998 From: scott@chronis.pobox.com (Scott) Date: Tue, 6 Oct 1998 13:59:31 -0400 Subject: [Mailman-Developers] CVS / Queuing problem In-Reply-To: ; from Ken Manheimer on Tue, Oct 06, 1998 at 01:31:14PM -0400 References: Message-ID: <19981006135931.15522@chronis.icgroup.com> On Tue, Oct 06, 1998 at 01:31:14PM -0400, Ken Manheimer wrote: | On Tue, 6 Oct 1998, Bavo De Ridder wrote: | | > I run a site with the mailman listmanager. I run several lists (10-15). | > I recently encountered the problem with the duplicates. For my site this | > is not only annoying but also inacceptable! | > | > I read in the archives that Scott has checked in some changes to the CVS | > to adres this problem (the files contact_transport, Mailman/Utils.py, | > Mailman/OutgoingQueue.py). This was on October 6. | | (Yay scott, btw!! I'm looking forward to hearing about results from | exercising the revisions...) no problems here yet. mailman is running on solaris 2.5.1, having an alternate host do mail delivery, and running 4 lists each with a decent amount of traffic and 15-350 subscribers. scott From klm@python.org Tue Oct 6 19:24:30 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 6 Oct 1998 14:24:30 -0400 (EDT) Subject: [Mailman-Developers] CVS / Queuing problem In-Reply-To: <19981006135931.15522@chronis.icgroup.com> Message-ID: Scott, i thought of a question about your changes which i haven't had the time to investigate. You mention that you're using setgid on the queue directories to enable proper permissions - my question concerns what people who are using existing installations need to do to set those permissions. In fact, more generally, does the installation mechanism need to be changed to set things up properly? Might we need a hook somewhere that detects the lack of these directory preparation, and reacts accordingly? Ken From bavo@ace.ulyssis.student.kuleuven.ac.be Tue Oct 6 19:30:06 1998 From: bavo@ace.ulyssis.student.kuleuven.ac.be (Bavo De Ridder) Date: Tue, 6 Oct 1998 20:30:06 +0200 (CEST) Subject: [Mailman-Developers] Duplicate mails Message-ID: Hello, I replaced the files Utils.py OutgoindQueue.py and contact_transport. Everything seems to work as it should, no duplicate mails anymore. I haven't tested that much, so I will keep this list informed. Thanks for the quick respons!!! Bavo De Ridder From scott@chronis.pobox.com Tue Oct 6 19:30:39 1998 From: scott@chronis.pobox.com (Scott) Date: Tue, 6 Oct 1998 14:30:39 -0400 Subject: [Mailman-Developers] CVS / Queuing problem In-Reply-To: ; from Ken Manheimer on Tue, Oct 06, 1998 at 02:24:30PM -0400 References: <19981006135931.15522@chronis.icgroup.com> Message-ID: <19981006143039.11741@chronis.icgroup.com> On Tue, Oct 06, 1998 at 02:24:30PM -0400, Ken Manheimer wrote: | Scott, i thought of a question about your changes which i haven't had | the time to investigate. | | You mention that you're using setgid on the queue directories to enable | proper permissions - my question concerns what people who are using | existing installations need to do to set those permissions. In fact, | more generally, does the installation mechanism need to be changed to | set things up properly? I don't think so... all that's necessary is that $prefix/data is setgid mailman. Both my mailman installs have this and i don't recall changing the perms for that directory manually at all. in short, i'm pretty sure that the current install takes care of that. | Might we need a hook somewhere that detects the | lack of these directory preparation, and reacts accordingly? personally, I'd like to see a general "mmcheck" script or something that looks at all the directory permissions and reports any problems. i've seen other directories ($prefix/mail and $prefix/cgi) mysteriously drop their setgid status somehow (whether or not it was my own fault i doj't know) and the resulting problems can be really hard to identify. mmcheck would be pretty simple -- just stat all the directories and compare to a preset dict of what they should be. scott From klm@python.org Tue Oct 6 19:42:45 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 6 Oct 1998 14:42:45 -0400 (EDT) Subject: [Mailman-Developers] CVS / Queuing problem In-Reply-To: <19981006143039.11741@chronis.icgroup.com> Message-ID: On Tue, 6 Oct 1998, Scott wrote: > I don't think so... all that's necessary is that $prefix/data is > setgid mailman. Both my mailman installs have this and i don't recall > changing the perms for that directory manually at all. in short, i'm > pretty sure that the current install takes care of that. In the current Makefile this seems to be the case. I don't see this particular chmod in the 1.0b4 Makefile, though the data dir on my python.org installation is set that way, so i'm not sure. Barry? > | Might we need a hook somewhere that detects the > | lack of these directory preparation, and reacts accordingly? > > personally, I'd like to see a general "mmcheck" script or something > that looks at all the directory permissions and reports any problems. > i've seen other directories ($prefix/mail and $prefix/cgi) > mysteriously drop their setgid status somehow (whether or not it was > my own fault i doj't know) and the resulting problems can be really > hard to identify. Agreed! That would be great - this should go on john's todo list, if it's not already there. > mmcheck would be pretty simple -- just stat all the directories and > compare to a preset dict of what they should be. I would be surprised if there aren't some other simple sanity checks that would make the job of finding and correcting setup flaws much easier... Ken From scott@chronis.pobox.com Tue Oct 6 19:46:52 1998 From: scott@chronis.pobox.com (Scott) Date: Tue, 6 Oct 1998 14:46:52 -0400 Subject: [Mailman-Developers] CVS / Queuing problem In-Reply-To: ; from Ken Manheimer on Tue, Oct 06, 1998 at 02:42:45PM -0400 References: <19981006143039.11741@chronis.icgroup.com> Message-ID: <19981006144652.65112@chronis.icgroup.com> On Tue, Oct 06, 1998 at 02:42:45PM -0400, Ken Manheimer wrote: | > personally, I'd like to see a general "mmcheck" script or something | > that looks at all the directory permissions and reports any problems. | > i've seen other directories ($prefix/mail and $prefix/cgi) | > mysteriously drop their setgid status somehow (whether or not it was | > my own fault i doj't know) and the resulting problems can be really | > hard to identify. | | Agreed! That would be great - this should go on john's todo list, if | it's not already there. | | > mmcheck would be pretty simple -- just stat all the directories and | > compare to a preset dict of what they should be. | | I would be surprised if there aren't some other simple sanity checks | that would make the job of finding and correcting setup flaws much | easier... suggestions? scott From klm@python.org Tue Oct 6 20:26:27 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 6 Oct 1998 15:26:27 -0400 (EDT) Subject: [Mailman-Developers] CVS / Queuing problem In-Reply-To: <19981006144652.65112@chronis.icgroup.com> Message-ID: On Tue, 6 Oct 1998, Scott wrote: > On Tue, Oct 06, 1998 at 02:42:45PM -0400, Ken Manheimer wrote: > > | I would be surprised if there aren't some other simple sanity checks > | that would make the job of finding and correcting setup flaws much > | easier... > > suggestions? I'm interested in suggestions, too. The kinds of things that spring to my mind are mostly concerning existing data and resource files: - verify that the location and permissions of the set*id wrapper excecutables are as expected - verify that the locations of the enwrapped scripts are as expected - check properness of permissions of existing maillist dbs - enable writing - likewise existing log files, if existing, enable writing These are just off the top of my head. I drew the line at going into internal data structures (like, not checking version settings on maillist objects - that's up to the versioning stuff, MailList.CheckVersion() and versions.Update()), and at examining external system files (ie, aliases, pipermail). Not that i would want to hold off on starting such a thing for these considerations - they can always be added, and i think they ought be. The trick in starting even a simple version of mmcheck, that just checks the directory permissions, is getting the autoconf stuff to set it properly from a mmcheck.in. Or maybe it can get the settings from the mm_cfg module - but then it would depend on *finding* the mm_cfg file, not sure how independent the mmcheck should be. (I'm inclined to have mmcheck depend on mm_cfg, and be a big error if it doesn't get it, period.) This all is thinking out loud, tho! Ken From julian7@kva.hu Wed Oct 7 11:37:25 1998 From: julian7@kva.hu (Balazs Nagy) Date: Wed, 7 Oct 1998 12:37:25 +0200 (CEST) Subject: [Mailman-Developers] Cookie error? Message-ID: Hiyas, Recently I noticed that my mailman's www admin tool didn't work: Apache says error 500 (permature error before script headers or sort of). The bug is in line 65 (admin.py). If I put return before Cookie constructor, it works well (without security): if os.environ.has_key('HTTP_COOKIE'): -> c = Cookie.Cookie( os.environ['HTTP_COOKIE'] ) if c.has_key(list_name + "-admin"): OK, i've done with this but I dunno anything about cookies. What bug is this? -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 From scott@chronis.pobox.com Wed Oct 7 11:43:44 1998 From: scott@chronis.pobox.com (Scott) Date: Wed, 7 Oct 1998 06:43:44 -0400 Subject: [Mailman-Developers] Cookie error? In-Reply-To: ; from Balazs Nagy on Wed, Oct 07, 1998 at 12:37:25PM +0200 References: Message-ID: <19981007064344.32247@chronis.icgroup.com> what error occurred on that line? scott On Wed, Oct 07, 1998 at 12:37:25PM +0200, Balazs Nagy wrote: | Hiyas, | | Recently I noticed that my mailman's www admin tool didn't work: Apache says | error 500 (permature error before script headers or sort of). The bug is in | line 65 (admin.py). If I put return before Cookie constructor, it works | well (without security): | | if os.environ.has_key('HTTP_COOKIE'): | -> c = Cookie.Cookie( os.environ['HTTP_COOKIE'] ) | if c.has_key(list_name + "-admin"): | | OK, i've done with this but I dunno anything about cookies. | | What bug is this? | -- | Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu | PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 | | | _______________________________________________ | Mailman-Developers maillist - Mailman-Developers@python.org | http://www.python.org/mailman/listinfo/mailman-developers | From julian7@kva.hu Wed Oct 7 14:27:45 1998 From: julian7@kva.hu (Balazs Nagy) Date: Wed, 7 Oct 1998 15:27:45 +0200 (CEST) Subject: [Mailman-Developers] Cookie error? In-Reply-To: <19981007064344.32247@chronis.icgroup.com> Message-ID: On Wed, 7 Oct 1998, Scott wrote: > what error occurred on that line? > > scott It is a good question. I couldn't find *any* error logs. Just the permature error. -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 From scott@chronis.pobox.com Wed Oct 7 19:39:57 1998 From: scott@chronis.pobox.com (Scott) Date: Wed, 7 Oct 1998 14:39:57 -0400 Subject: [Mailman-Developers] Document handling Message-ID: <19981007143957.24418@chronis.icgroup.com> I've been working on making mailman work with built in archiving from The Dragon De Monsyne's web archiving patches, and have stumbled on something that definitely seems a good thing to discuss. His patches use DocumentTemplate, a large and free and fairly mature document handling mechanism from digital creations (www.digicool.com). While DocumentTemplate supports lots of stuff with document handling that the current mailman distribution does not support, there are some issues in incorporating it. First of all, I'd like very much to see mailman have a single uniform document management interface. So this leads to the obvious question: should mailman use it's current mechanism accross the board or should it use DocumentTemplate, or something else? Here's some thinking out loud on the top: DocumentTemplate is in many ways a better document interface. It supplies conditional sections, expression evaluation, list iteration, variable replacement, etc. DocumentTemplate is large (20 files currently). It's size works fine in the context of producing archiving files, but personally, I'd be reluctant to use it in cgi's because I've found it's loading time to be pretty slow, and I've found lots of mailman cgi's a bit sluggish. Personally, I'd use it only with pcgi or some cgi accelerator. DocumentTemplate may not work well as a replacement for htmlformat because of all the mailman-specific stuff in the htmlformat module. Whatever is decided, it'd be nice to consider that there's probably a good number of people interested in builtin web archiving, and so some provision may have to be made to make that available before a full document solution is arrived at if a full document solution would take a while. scott From julian7@kva.hu Fri Oct 9 11:37:57 1998 From: julian7@kva.hu (Balazs Nagy) Date: Fri, 9 Oct 1998 12:37:57 +0200 (CEST) Subject: [Mailman-Developers] my patches are availabe via www Message-ID: Hiyas, My patches can be downloaded from http://www.kva.hu/~mailman. Please check'em out. I've fixed some bugs in'em. Bug reports are welcomed. -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 From John@list.org Fri Oct 9 19:56:16 1998 From: John@list.org (John Viega) Date: Fri, 9 Oct 1998 11:56:16 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] archiving and piper In-Reply-To: ; from Darren Henderson on Fri, Oct 09, 1998 at 02:40:23PM -0400 References: Message-ID: <19981009115616.A11902@viega.org> Darren, The version of Mailman in the CVS tree has integrated archiving support again, finally, thanks to Dragon and Scott. It'll be in the next release. I think that's going to be the easiest path to archives, to upgrade when that release comes out. There's a new release around the corner; we need to integrate some patches from Nagy, and then test it to make sure it works out of the box to some reasonable degree. I've got time dedicated to that this weekend, and during the week next week. So I'd say there'll be a new release with archiving in it by the middle of next week, perhaps earlier. John On Fri, Oct 09, 1998 at 02:40:23PM -0400, Darren Henderson wrote: > > Does anyone have any pointers to info on configuring/installing piper and > getting it working with mailman. Perhaps I'm overlooking it in the > distributions I pulled in or perhaps I'm looking to hard and its simpler > then I'm thinking it should be:) > > ______________________________________________________________________ > Darren Henderson darren@jasper.somtel.com > > Help fight junk e-mail, visit http://www.cauce.org/ > > > ------------------------------------------------------ > Mailman-Users maillist - Mailman-Users@python.org > http://www.python.org/mailman/listinfo/mailman-users From scott@chronis.pobox.com Fri Oct 9 23:56:31 1998 From: scott@chronis.pobox.com (Scott) Date: Fri, 9 Oct 1998 18:56:31 -0400 Subject: [Mailman-Developers] my patches are availabe via www In-Reply-To: ; from Balazs Nagy on Fri, Oct 09, 1998 at 12:37:57PM +0200 References: Message-ID: <19981009185631.48623@chronis.icgroup.com> I've integrated 3 of the 4 required patches with the mailman distribution, but i've gotten a little stumped with the cmdhandler patch. in MailList.__init__, I had to put InitTempVars before MailCmdHandler.__init__(self) (the patch for MailList.py failed for some reason, it may have been changes to the source i was applying it to though). in the MailCommandHandler module, I had to add a "cmdmode = 0" near the top of ParseMailCommand because it wasn't defined and was throwing a NameError if you sent it a plain "help" command. same sort of thing happened with the definition of the "txt" variable when sending a plain "help" command. in addition, I had to substitute .GetAbsoluteScriptURL(mm_cfg.{CGI_LISTINFO,CGI_ADMIN}) with GetAbsoluteScriptURL("listinfo") or GetAbsoluteScriptURL("admin"). where did you add mm_cfg.CGI_LISTINFO and why? do you think we could come up with anything to prettify the output of the "edit all" command -- and perhaps add comments to each variable it spits out? could we maybe replace the "setattr " command syntax with: # # = scott On Fri, Oct 09, 1998 at 12:37:57PM +0200, Balazs Nagy wrote: | Hiyas, | | My patches can be downloaded from http://www.kva.hu/~mailman. Please | check'em out. | | I've fixed some bugs in'em. | | Bug reports are welcomed. | -- | Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu | PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 | | | | _______________________________________________ | Mailman-Developers maillist - Mailman-Developers@python.org | http://www.python.org/mailman/listinfo/mailman-developers | From scott@chronis.pobox.com Sat Oct 10 02:57:24 1998 From: scott@chronis.pobox.com (Scott) Date: Fri, 9 Oct 1998 21:57:24 -0400 Subject: [Mailman-Developers] digest/non digest subscribers Message-ID: <19981009215724.63588@chronis.icgroup.com> some folks using mailman that were recent majordomo users were subscribers to both the digest and the regular list traffice, and miss that option when using mailman. though i personally don't understand why someone would want this option, especially when the equivalent of the digest is available from the web archives, it might be a nice thing to make things smoother for former majordomo users. thoughts? scott From scott@chronis.pobox.com Sat Oct 10 02:58:07 1998 From: scott@chronis.pobox.com (Scott) Date: Fri, 9 Oct 1998 21:58:07 -0400 Subject: [Mailman-Developers] posters variable Message-ID: <19981009215807.10217@chronis.icgroup.com> currently, in mailman when you have anyone listed in the posters setting, there are no options to let people set whether the posters should automatically include the digest and/or regular subscribers. majordomo lets you do this (although with some awkward syntax -- see mj's restrict_post). perhaps we could add 2 more boolean variables like posters_auto_include_digest_subscribers and posters_auto_include_regular_subscribers to address this. Even though it's not really common, i don't believe it's that unusual for a list to allow only its subscribers plus a handful of other people to post. scott From scott@chronis.pobox.com Sat Oct 10 16:39:28 1998 From: scott@chronis.pobox.com (Scott) Date: Sat, 10 Oct 1998 11:39:28 -0400 Subject: [Mailman-Developers] mass subscribe from admin cgi Message-ID: <19981010113928.52308@chronis.icgroup.com> I've seen that on the TODO list is some way of making the admin cgi fork whenever it does the mass subscription. the idea is not make the cgi hang for too long. Is there any way of still getting the listing of successfully subscribed and error messages when doing this? scott From tomas@euronetics.se Sat Oct 10 18:13:53 1998 From: tomas@euronetics.se (Tomas Fasth) Date: Sat, 10 Oct 1998 19:13:53 +0200 Subject: [Mailman-Developers] Problem accessing cvs repository as anoncvs Message-ID: <361F95D1.D81C029E@euronetics.se> I just tried an update from anoncvs@cvs.python.org and got the following: cvs server: cannot open /projects/cvsroot/mailman/templates/help.txt,v: Permission denied cvs server: cannot open /projects/cvsroot/mailman/templates/help.txt,v: Permission denied cvs server: templates/help.txt is no longer in the repository Do anyone know what caused this? As I can understand from the latest postings to mailman-checkin Scott is the last one making a commit to help.txt. Maybe something got messed up then. Tomas From scott@chronis.pobox.com Sat Oct 10 18:16:45 1998 From: scott@chronis.pobox.com (Scott) Date: Sat, 10 Oct 1998 13:16:45 -0400 Subject: [Mailman-Developers] Problem accessing cvs repository as anoncvs In-Reply-To: <361F95D1.D81C029E@euronetics.se>; from Tomas Fasth on Sat, Oct 10, 1998 at 07:13:53PM +0200 References: <361F95D1.D81C029E@euronetics.se> Message-ID: <19981010131645.20815@chronis.icgroup.com> --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii I don't know wht might have happened, but in the mean time, I've attached the file templates/help.txt. scott On Sat, Oct 10, 1998 at 07:13:53PM +0200, Tomas Fasth wrote: | I just tried an update from anoncvs@cvs.python.org and got the | following: | | cvs server: cannot open /projects/cvsroot/mailman/templates/help.txt,v: | Permission denied | cvs server: cannot open /projects/cvsroot/mailman/templates/help.txt,v: | Permission denied | cvs server: templates/help.txt is no longer in the repository | | Do anyone know what caused this? As I can understand from the latest | postings to mailman-checkin Scott is the last one making a commit to | help.txt. Maybe something got messed up then. | | Tomas | | | | _______________________________________________ | Mailman-Developers maillist - Mailman-Developers@python.org | http://www.python.org/mailman/listinfo/mailman-developers | --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="help.txt" Help for %(listname)s mailing list: This is email command help for version %(version)s of the "Mailman" list manager. The following describes commands you can send to get information about and control your subscription to Mailman lists at this site. A command can be in the subject line or in the body of the message. Note that much of the following can also be accomplished via the web, at: %(listinfo_url)s In particular, you can use the Web site to have your password sent to your delivery address. List specific commands (subscribe, who, etc) should be sent to the *-request address for the particular list, e.g. for the 'mailman' list, use 'mailman-request@...'. About the descriptions - words in "<>"s signify REQUIRED items and words in "[]" denote OPTIONAL items. Do not include the "<>"s or "[]"s when you use the commands. The following commands are valid: subscribe [password] [digest-option] [address=
] Subscribe to the mailing list. Your password must be given to unsubscribe or change your options. When you subscribe to the list, you'll be reminded of your password periodically. 'digest-option' may be either: 'nodigest' or 'digest' (no quotes!) If you wish to subscribe an address other than the address you send this request from, you may specify "address=" (no brackets around the email address, no quotes!) unsubscribe [address] Unsubscribe from the mailing list. Your password must match the one you gave when you subscribed. If you are trying to unsubscribe from a different address than the one you subscribed from, you may specify it in the 'address' field. who See everyone who is on this mailing list. info View the introductory information for this list. lists See what mailing lists are run by this Mailman server. help This message. set