Mailman-Developers March 1999

mailman-developers@python.org

32 participants
64 discussions

problems with who ?
by Gergely Madarasz 03 Apr '99

03 Apr '99

I'm running mailman 1.0b10 This is all I get from a who request. ---------- Forwarded message ---------- Date: Wed, 31 Mar 1999 10:48:22 +0200 From: linux-flame-request(a)mlf.linux.rulez.org To: gorgo(a)caesar.elte.hu Subject: Mailman results for linux-flame ***** who Digest Members: anovak(a)nap-szam.hu atom(a)sophia.jpte.hu b-b0mb(a)freemail.c3.hu ba... Non-Digest Members: a7803268(a)unet.univie.ac.at a_linux(a)freemail.c3.hu acsosz(a)mail.da...

3 3

mailman and AFS?
by Christopher Lindsey 31 Mar '99

31 Mar '99

Well, I'm about to try doing some funky stuff that's going to require source changes, etc. But before I jump into it, I've got some questions. I want to setup mailman here at NCSA and gradually start phasing out majordomo. Here's the current set up: 4 mail servers NFS-RAID sharing mail spools, procmail recipes, etc. AFS (this is a common filesystem everywhere) 8 round-robined Web servers (DocumentRoot served from AFS) Because AFS is the only available common filesystem for both the mail servers and the Web servers, I'll need to setup mailman there. Now for the tricky part. AFS doesn't use standard UNIX permissions, but instead depends on ACLs (ours uses Kerberos V for authentication). To be able to write into the AFS space, any program or shell must have a valid AFS token. I can do this by creating a "keytab" file; basically, that randomizes the password but lets me use it in shell scripts, etc. I just need to kinit against this file, do my operations, then do a kdestroy. Now for my questions: o where should I put these calls? I'm guessing that they should be in wrapper, but do I also need to put it into every binary in $prefix/cgi-bin? It appears that way... o am I going to run into any locking issues with multiple email and Web servers, or does mailman handle this? If so, how? AFS (like NFS) often has problems with flock() or fcntl() locking (so dot-locking is the preferred method). o does mailman actually do any permissions checking on files or directories? These checks would fail in AFS Any pointers and/or answers would be appreciated. Thanks, Chris

1 0

exim - Failure to exec script- gid question
by nbecker＠fred.net 30 Mar '99

30 Mar '99

I'm using mailman-1.0b10 + exim-2.10. Mar 30 13:10:08 nbeckerpc Mailman mail-wrapper: Failure to exec script. WANTED gid 12, GOT gid 99. (Reconfigure to take 99?) I can reconfigure mailman or exim to set the gid, but why is it needed at all? Since wrapper is sgid, why does it care what gid was used to invoke it? Just additional security check?

1 0

Re: [Mailman-Users] mailman, postifx, and bsdos3
by Barry A. Warsaw 29 Mar '99

29 Mar '99

>>>>> "GME" == George M Ellenburg <gmelists(a)caffeine.sundial.net> writes: GME> At the request of some of my customers, I've recently GME> installed mailman on BSD 3.1, with Postfix beta-19990317-pl02 GME> as the transport. GME> Frankly, I'm a little confused with regards to the install GME> instructions. Was wondering if anyone can provide some GME> elightenment. GME> I'm getting the following error when trying to create a test list: | sundial:~/bin $ whoami | mailman | sundial:~/bin $ ./newlist | Enter the name of the list: test | Enter the email of the person running the list: gme(a)caffeine.sundial.net | Initial test password: testpassword | Traceback (innermost last): | File "./newlist", line 141, in ? | raise SystemExit(main(sys.argv)) | File "./newlist", line 91, in main | newlist.Create(list_name, owner_mail, pw) | File "/u1/mailman/Mailman/MailList.py", line 658, in Create | self.Lock() | File "/u1/mailman/Mailman/MailList.py", line 1213, in Lock | self._lock_file.lock('w|', 1) | File "/usr/local/lib/python1.5/posixfile.py", line 190, in lock | flock = fcntl.fcntl(self._file_.fileno(), cmd, flock) | IOError: (22, 'Invalid argument') | sundial:~/bin $ I'm Cc'ing the Mailman developers and Guido on this message, because I suspect there's a problem with your Python on your operating system (BSD 3.1). For some reason lock() method on the posixfile object is failing. This method eventually calls down to fcntl() and the `|' modifier translates to F_SETLKW. fcntl(2) says that this could fail and return EINVAL (i.e. errno 22) as described in my Solaris manpage: EINVAL The cmd argument is invalid; or the cmd argu- ment is F_DUPFD and arg is negative or greater than or equal to OPEN_MAX; or the cmd argument is F_GETLK, F_GETLK64, F_SETLK, F_SETLK64, F_SETLKW, or F_SETLKW64 and the data pointed to by arg is not valid; or fildes refers to a file that does not support locking. I've never seen this happen before, at least in the context of Mailman, so that's why I'm suspecting your OS, of which I have no experience. What does your sys.platform say? Maybe someone else has some idea about why this is failing. -Barry

2 1

1.0b10
by Barry A. Warsaw 29 Mar '99

29 Mar '99

Folks, please don't upgrade to 1.0b10 just yet. I think there's still a problem with address matching and case preservation. I have a fix and am going to do a bunch of testing, /and/ hopefully get some sanity checking from Ken on a few things. Once I get this fixed, I will release 1.0b11. Note that this should be unrelated to the problem that Clark is having. -Barry

1 0

Mailman 1.0b10
by Barry A. Warsaw 26 Mar '99

26 Mar '99

Hi everyone, I'm releasing Mailman 1.0b10 today; hopefully we'll have more luck with this than b9. I need to concentrate on other things for a while, now that python.org seems to be smoothly running this version. Unless there are showstopper bugs, I would like this version to be 1.0 final, so please do bang on it a lot. If you do find bugs, it would be great if you can enter them into the Jitterbug database. See http://www.python.org/mailman-bugs I know there's a lot y'all would like to see done. Weighed against the slippage in when I thought 1.0 final would be out, I think we have to just be happy with what we've got for now, get it out the door, and then begin working on improvements. Like John said at LISA: "all mailing list managers suck, ours just sucks less" ... hopefully :-) Go to www.list.org to pick up the current tarball. Note that the old ftp URL won't work anymore. BE SURE TO READ THE `UPGRADING' FILE FOR IMPORTANT INFORMATION. There's still time to vote on the logo. Voting is closed whenever I do the first release candidate (no date set, but SOON). My priority for the next release will be to craft the Web pages for gnu.org, clean up documentation, and get things ready for the mass of new adopters (yeah!). I can't guarantee that I'll be hacking any code unless there's severe breakage in this tarball. Enjoy, and thanks everyone, -Barry

1 1

bulk add users "issues"
by Jeff Hahn 25 Mar '99

25 Mar '99

couple of issues: 1. I've also run into a problem I believe I remember reading about on this list. add_members seg faults at about 500 users added in a run. I've got the dumpfile, but since I don't have python compiled with debugging, not sure it's of any value to anyone. (RH 5.2, Python 1.5.1, latest CVS of Mailman) 2. When bulk adding members (either thru the web page or add_members) the digest type appears to be random (not the default digest mode as defined for the list) I've scanned thru the source, but I don't see anything "obvious", but I've probably overlooked something easy. -Jeff

1 0

Re: [Mailman-Developers] Does anyone else see these?
by J C Lawrence 24 Mar '99

24 Mar '99

On 25 Mar 1999 00:34:14 +0100 Harald Meland <Harald.Meland(a)usit.uio.no> wrote: > At one time I heard a rumour that someone was to implement VERP[1] > support in Mailman -- and I even imagined to have heard that the > implementation would do VERP on only every Nth posting to keep > down list latency. I implemented something like this for a home-grown list server, and chattered about that design on this list. I'm not aware of anyone buying into the idea, and I've been far too busy with Linux/Merced to do more than wanly wish for it. -- J C Lawrence Internet: claw(a)kanga.nu ---------(*) Internet: claw(a)varesearch.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...

1 0

Re: [Mailman-Developers] MM1.0b9 Bug! (was: Setup prob: abs/rel CGI url)
by Harald Meland 24 Mar '99

24 Mar '99

[Christian Tismer] > I think it would be better for MM's public acceptance if there was > always a version known to be used in many installations. I, OTOH, don't think that'd solve anything much. The very reason for releasing Betas is to get rid of bugs. The intention is that each new Beta should have fewer bugs than any of the previous ones. Of course, due to human nature and Murphy's Law, whenever someone tries to fix a bug there is a non-zero probability that something else gets broken. > It would not have all new features, but also not the new bugs. Unless you trade away the Good of getting old bugs fixed, you can't avoid the Bad of maybe introducing new bugs. > In other words: If the latest beta needed a bug fix, why don't we > mark it as problematic and go back to, say, 1.0b7? IMHO, this might be a viable plan if we were talking about stable releases. We're not. We're talking about Beta releases. Cheers, -- Harald

1 0

Re: [Mailman-Developers] Does anyone else see these?
by Harald Meland 24 Mar '99

24 Mar '99

[J C Lawrence] > On Fri, 5 Mar 1999 01:17:53 -0600 (CST) > Christopher Lindsey<lindsey(a)ncsa.uiuc.edu> wrote: > > > Perhaps Mailman could add (yet another) header indicating the > > targetted recepient to help with this type of situation? Maybe > > X-Mailman-Recepient? Or it could be wrapped it into another header > > like X-BeenThere... > > One technique I used for my own list software (now defunct) was that > every N'th message to each subscriber was sent individually with > custom headers giving the subscription address, list name etc. At one time I heard a rumour that someone was to implement VERP[1] support in Mailman -- and I even imagined to have heard that the implementation would do VERP on only every Nth posting to keep down list latency. It would be a post-1.0 thing, of course -- but was I merely dreaming all this, or are actually anyone putting any work into this? If no-one are, then someone should be :-) [1] Variable Envelope Return Paths, see <URL:ftp://koobera.math.uic.edu/www/proto/verp.txt> for further description. -- Harald

1 0

2023

2022

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 March 1999