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...
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
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?
>>>>> "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
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
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
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
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...
[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
[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
