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
> 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.
> 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.
> 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
[ 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.
> 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
> 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
> 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
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.
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 \
[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
[ And just think how nicely it would integrate with a user
database... OK, OK, I'll stop teasing RSN ;) ]
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
"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:
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): File "/home/mailman/scripts/post", line 62, in main
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.
Scott Russell (scottrus(a)raleigh.ibm.com)
Linux Technology Center, System Admin
Red Hat Certified Engineer
-----BEGIN PGP SIGNED MESSAGE-----
There's a recipe for exim's configuration that makes it unnecessary to
add aliases to /etc/aliases for every mailing list.
driver = pipe
command = "/var/spool/smartlist/.bin/flist \
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"
Would this work? Comments?
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
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/>
-----END PGP SIGNATURE-----
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...
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.