Mailman 3 February 2000 - Mailman-Developers

Membership management chunking requires two authentications..
by Ted Cabeen 19 Jul '00

19 Jul '00

Mailman: 1.1 Python: 1.5.2 OS: Solaris 5.7 I don't know if this has been fixed in the CVS version, but I thought I'd submit it anyways. There seems to be a small authentication bug with the chunking in the membership management page. The page will load up correctly the first time it is accessed with the first chunk size shown. However, when you request a different chunk, it requires a reauthentication and then gives the chunk=0 page instead of the requested chunk. If you then click on the alternate chunk it loads fine. However, the additional click and authentication is annoying. -- Ted Cabeen http://www.pobox.com/~secabeen secabeen(a)pobox.com Check Website or finger for PGP Public Key secabeen(a)midway.uchicago.edu "I have taken all knowledge to be my province." -F. Bacon cococabeen(a)aol.com "Human kind cannot bear very much reality."-T.S.Eliot 73126.626(a)compuserve.com

3 4

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

02 May '00

[Thomas Wouters] > On Mon, Feb 07, 2000 at 09:31:44PM +0100, Ricardo Kustner wrote: > > > I wonder though what happens if some impatient moderator decides not to > > wait before the page finnishes loading, switches to a differen webpage and > > therefor breaks the python cgi process... will some approved posts stay in > > the queue instead? > > Try it out ! ;) It depends on the exact behaviour of both the > webbrowser and the webserver. Yup. This might produce a SIGPIPE, and/or the corresponding IOError EPIPE, and I've experienced that these didn't always get caught -- an attempt at a fix is near the end of run_main in <URL: http://www.uio.no/~hmeland/tmp/mailman-userdb/scripts/driver>, but I'm by no means positive that it's the Right fix. -- Harald

2 1

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

07 Apr '00

[Thomas Wouters] > On Mon, Feb 07, 2000 at 10:01:36PM +0100, Harald Meland wrote: > > > 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... > > Ah, very cool. You'll find my current version of LockFile.py > attached, for reference, as you asked. Thanks, I've skimmed through most of it now. > I think the link() solutions, as opposed to the rename() solution, > is a better one, if you'll premit me. Sure :) > For one, you can check on lock ownership by statting your own > lockfile, which should only be touched by you, instead of reading a > possibly highly volatile lockfile. You can also doublecheck the > lockfile inode, see if it is equal to your own lockfiles' inode, to > confirm that you have the lock. ... the downside being that if, e.g., anyone tries to read the info in the lockfile in the middle of a refresh(), they'll get a ValueError -- which your module seems to take care of, but it all looks a bit convoluted to my eyes. I especially dislike that lock() has to call locked() _after_ the check on ST_NLINK, because further down in lock() there's code that might break a lock it really shouldn't (if it weren't for the nonatomic-write-of-lock-contents issue). I also see some bugs that are fixed in my module but still present in yours, but those are rather irrelevant to this discussion (as they can easily be ported to your module if that's the one we'll go for). Does anyone but Thomas and me have any opinions on which locking scheme is preferrable? I guess I don't have any very strong feelings about the issue ;), so any sagely advise on the matter would be welcome. [ I've tried to model my version of the module as closely as possible after the way Exim does its lockfile locking, the idea being that Exim really should have been around long enough to have solved these things correctly. Reading the longish comment from ca. line 1206 and onwards in src/transports/appendfile.c of the Exim distribution proved very helpful to me. Of course, when it comes to lock stealing and other ugly (but needed, I guess) stuff, Exim couldn't provide much help. ] > Ah, well, I couldn't find any parts of Mailman in the CVS tree that > acually _called_ steal, so I couldn't figure out what it should do > in borderline cases. The only place I know of is cron/gate_news. > However, reading your LockFile.py made me realise how to steal the > lock. LockFile.steal() now does its utmost best to steal the lock, > only failing if someone else is busy stealing the lock from us. It > returns 1 for success, 0 for failure, mostly because I wanted it to > signify that in some way. ... but the caller should note that steal() returning 1 does not necessarily imply that it is the owner of the lock (anymore). The steal() stuff is bound to be full of race conditions, AFAICT -- so whether it returns anything doesn't really matter (IMHO), as the return code truly can't be trusted anyway. Cheers, -- Harald

2 1

Re: [Mailman-Developers] cron/gate_news watermark == 0
by Harald Meland 07 Apr '00

07 Apr '00

[Jim Tittsler] > A watermark value of 0 is used for two different purposes in cron/gate_news: > 1. the group has never been gatewayed, so "catch up" to the highest article > number > 2. the highest article number seen for the group is 0 (which can be a valid > "high article number" before the first posting in a newly created > newsgroup) > The result of this is the first article posted to the newly created newsgroup > fails to get gatewayed to the mailing list because the watermark for that > group is (still) 0 which is used as a flag to "catch up" so all that happens > is the watermark gets set to 1. > > I believe I have fixed that in my copy by using the value None for the first > time a group is gatewayed, allowing proper processing when the watermark is > truly article number 0. Hmmmm... When checking the contents of my "data/gate_watermarks" marshal, I find several old mailing lists with an entry stating that their watermark is 0 -- even though these lists aren't actually gating any newsgroups. As all these lists are rather old, I guess this could be how things were stored in some early Mailman version -- back when gate_news were forking processes to gate _all_ lists, regardless of whether the list in question had requested that any gating should be done, and the watermark file was written to by each and every child... On checking this with CVS, it appears that revision 1.7 of gate_news indeed has the behaviour I suspected, while 1.8, which was checked in 1998/12/18 00:22:23, seems to do it "right". The upshot of this is that any list touch by rev. 1.7 (and maybe earlier) which do not do any gating would possibly get *all* the messages present in the group it's gating from posted to it if it started gating after your patch was applied. A possible way to approach all this would be to have "make update" replace those 0 values in gate_watermarks with None values iff there are no other None values (i.e. only change things on the first time "make update" is run). Or, even better, move the per-list watermark info from gate_watermarks into the list's config.db, replacing any 0 values in gate_watermarks with None values in config.db. This has the advantage of reducing the number of different files that would have to be changed when cloning/renaming a list. -- Harald

3 2

a more uniform interface to private and public archives
by Todd Pfaff 13 Mar '00

13 Mar '00

for mailman-1.1, the installation documentation suggests to create, for example, an 'Alias' path for the web server to the mailman public archives and a 'ScriptAlias' cgi-bin path to the private archives. what i'd like to suggest is that we make the interface more uniform by eliminating the 'Alias' path and access both private and public archives via a single cgi-bin interface. if the archive is private we require authentication, if not we simply bypass the authentication. i've done this with my mailman installation by doing the following: - created a new version of the MailMan/Cgi/private.py program - in mm_cfg.py, set PUBLIC_ARCHIVE_URL = '/mailman/private' PRIVATE_ARCHIVE_URL = '/mailman/private' - these could then be collapsed into one ARCHIVE_URL - we could also replace PUBLIC_ARCHIVE_FILE_DIR = os.path.join(PREFIX, 'archives/public') PRIVATE_ARCHIVE_FILE_DIR = os.path.join(PREFIX, 'archives/private') with one ARCHIVE_FILE_DIR, and we could also get rid of the public and private subdirectories altogether. in the new private.py i check listobj.archive_private and if it's set to 1 i do the usual private authentication as before. if it's not 1, i set is_auth to 1 and fall through. that's it. very clean and simple. does anyone see any problems with this? i think it certainly makes things more clear and straightforward. -- Todd Pfaff \ Email: pfaff(a)mcmaster.ca Computing and Information Services \ Voice: (905) 525-9140 x22920 ABB 132 \ FAX: (905) 528-3773 McMaster University \ Hamilton, Ontario, Canada L8S 4M1 \

2 1

Re: [Mailman-Developers] Admin overview page should list number of pending admin requests per list
by Harald Meland 02 Mar '00

02 Mar '00

[Barry A. Warsaw] > >>>>> "BP" == Bruce Perens <bruce(a)perens.com> writes: > > BP> Here's a feature request. I administrer about 10 lists. To see > BP> what the pending admin requests are, I either have to look in > BP> my mailbox for nudges from the server, or click on the "handle > BP> administrative requests" link for _every_ list. What I want > BP> is to be able to see this for all lists at a glance. > > As admin for about a dozen lists on python.org, I completely agree! But that means that _anyone_ can see whether there are held messages in a list -- which really is giving out more info than appropriate (at least in some cases). I think there should be a separate "userinfo" CGI script which, after proper autentication, shows what lists that user is 1) member of and 2) admin for. Putting the info you both crave for on that page would be Good. [ And just think how nicely it would integrate with a user database... OK, OK, I'll stop teasing RSN ;) ] -- Harald

2 1

sendmail exit 2 error on lists
by Scott Russell 26 Feb '00

26 Feb '00

All - I did make that migration from majordomo to Mailman 1.2 beta 1 (checked out of cvs on 02/23/00) and only ran into one issue. One of my users had the following email address while using majordomo: "Tim O'Flynn/DUB/xxxx" <Tim_O'Flynn(a)xxxx.com> I used the bin/add_members script to import the list. This had no problems. The resulting email address in Mailman was: tim_o'flynn(a)xxxx.com The problem was sending mail to this list would result in the follwing error: post(32390): File "/home/mailman/scripts/post", line 86, in ? post(32390): main() post(32390): File "/home/mailman/scripts/post", line 62, in main post(32390): mlist.Post(msg) post(32390): File "/home/mailman/Mailman/MailList.py", line 1260, in Post post(32390): Mailman.Handlers.HandlerAPI.DeliverToList(self, msg) post(32390): File "/home/mailman/Mailman/Handlers/HandlerAPI.py", line 55, in DeliverToList post(32390): func(mlist, msg) post(32390): File "/home/mailman/Mailman/Handlers/Sendmail.py", line 88, in process post(32390): raise SendmailHandlerError(errcode) post(32390): Mailman.Handlers.Sendmail . SendmailHandlerError : 2 Also, a MAILER-DEAMON error was sent to the sender whenever they posted to the list. The error showed the above trace back and that a shell error had occured while processing the mail. Any thoughts on how to solve this? It should be easy to replicate. If someone writes a patch and it get's commited to cvs I'll update my copy and confirm the patch works. BTW, once again, I know I've said it before, THANK YOU FOR AN OUTSTANDING PRODUCT. Oh, I'm using postfix as my mail agaent, btw. Not sure if that mattered in the whole thing. -- Regards, Scott Russell (scottrus(a)raleigh.ibm.com) Linux Technology Center, System Admin Red Hat Certified Engineer

2 1

mailman, aliases and exim
by Juergen A. Erhard 25 Feb '00

25 Feb '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There's a recipe for exim's configuration that makes it unnecessary to add aliases to /etc/aliases for every mailing list. list_transport: driver = pipe command = "/var/spool/smartlist/.bin/flist \ ${local_part}${local_part_suffix}" current_directory = /var/spool/smartlist home_directory = /var/spool/smartlist user = smartlist group = list Would/is something like this possible for mailman? This std aliases fragment would hint at needing to replace wrapper with a smart-wrapper or such that groks the list addresses (test, test-admin, etc) and calls wrapper as appropriate. ## test mailing list ## created: 27-Jan-2000 root test: "|/var/lib/mailman/mail/wrapper post test" test-admin: "|/var/lib/mailman/mail/wrapper mailowner test" test-request: "|/var/lib/mailman/mail/wrapper mailcmd test" owner-test: test-admin test-owner: test-admin Would this work? Comments? Bye, J PS: Need to get the Mailman source... as that wrapper ain't Python ;-) - -- Jürgen A. Erhard eMail: jae(a)ilk.de phone: (GERMANY) 0721 27326 MARS: http://JuergenErhard.tripod.com/mars_index.html The GNU Project (http://www.gnu.org) Win32 has many known work arounds. For example, Linux. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Use Mailcrypt and GnuPG <http://www.gnupg.org/> iEYEARECAAYFAji1k9kACgkQN0B+CS56qs2i1QCfdKXgC/3bvk9VCyDFWThx2Xus iWsAoIz+jUdl/12GImZTjTzlpKpeK4ha =JdHL -----END PGP SIGNATURE-----

2 1

mailman development
by Ricardo Kustner 24 Feb '00

24 Feb '00

Hi, I've been following mailman development since somewhere around april/may 1999. I was just reading back the archives and I remember that several times interesting discussions started on how it could be made easier for people to contribute to mailman development (cvs branches, bitkeeper and other things), but unfortunately there haven't been made much decissions about this so far (AFAIK)... I know the core developers are busy with other projects too, but the point of this email is that i'm hoping to bring this discussion back to life and that it results in some changes that will speed up development ... Also please have a look at this message Barry posted last year, and the thread that follows it... http://www.python.org/pipermail/mailman-developers/1999-October/001415.html Ricardo. --

2 1

mail/news gateway
by Gergely Madarasz 24 Feb '00

24 Feb '00

Hello, I've fixed now the MODE reader problems in the debian package of mailman (using the cvs nntplib.py in Mailman/pythonlib)... And now I was wondering... what happens if the newserver does not accept connections when mailman wants to gateway a post from mail to news... is there a queueing mechanism for nntp just like there is for smtp in case the MTA is down ? -- Madarasz Gergely gorgo(a)sztaki.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://mlf.linux.rulez.org/

5 11