From bwarsaw@python.org Mon May 1 18:43:04 2000
From: bwarsaw@python.org (Barry Warsaw)
Date: Mon, 1 May 2000 13:43:04 -0400 (EDT)
Subject: [Mailman-Developers] New LockFile.py
Message-ID: <14605.49704.849479.12542@anthem.cnri.reston.va.us>
Folks,
Based on much input from Thomas and Harald, I've got a new version of
LockFile.py which should work much better for high volume sites. This
has the fixed linking direction, the implementation has been cleaned
up considerably, and I think I've eliminated race conditions as much
as possible.
One casualty is steal(). The current Mailman CVS source doesn't use
it, and I didn't like the semantics anyway, so I simply got rid of the
method. I don't know if any of the "unofficial" patches out there
still use it though.
The one questionable aspect of the new LockFile.py is that it uses the
mtime of the file as the lock's lifetime. This works great for
avoiding race conditions but means that Mailman is setting mtime's of
the files to some time in the future. Is anybody aware of OSes where
this will be a problem? Linux and Solaris both seem to stay happy.
I've added some unit testing which gives me confidence in this module,
but I haven't tried it yet on python.org. And I'm still waiting for
Thomas to give it his usual bulletproofing test. Still, I think it's
time for other eyes to take a look. I'd appreciate any feedback you
folks can provide.
-Barry
-------------------- snip snip --------------------
# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
"""Portable, NFS-safe file locking with timeouts.
This code implements an NFS-safe file-based locking algorithm influenced by
the GNU/Linux open(2) manpage, under the description of the O_EXCL option.
From RH6.1:
[...] O_EXCL is broken on NFS file systems, programs which rely on it
for performing locking tasks will contain a race condition. The
solution for performing atomic file locking using a lockfile is to
create a unique file on the same fs (e.g., incorporating hostname and
pid), use link(2) to make a link to the lockfile. If link() returns
0, the lock is successful. Otherwise, use stat(2) on the unique file
to check if its link count has increased to 2, in which case the lock
is also successful.
The assumption made here is that there will be no `outside interference',
e.g. no agent external to this code will have access to link() to the affected
lock files.
LockFile objects support lock-breaking so that you can't wedge a process
forever. This is especially helpful in a web environment, but may not be
appropriate for all applications.
Locks have a `lifetime', which is the maximum length of time the process
expects to retain the lock. It is important to pick a good number here
because other processes will not break an existing lock until the expected
lifetime has expired. Too long and other processes will hang; too short and
you'll end up trampling on existing process locks -- and possibly corrupting
data. In a distributed (NFS) environment, you also need to make sure that
your clocks are properly synchronized.
Locks can also log their state to a log file. When running under Mailman, the
log file is placed in a Mailman-specific location, otherwise, the log file is
called `LockFile.log' and placed in the temp directory (calculated from
tempfile.mktemp()).
"""
# This code has undergone several revisions, with contributions from Barry
# Warsaw, Thomas Wouters, Harald Meland, and John Viega. It should also work
# well outside of Mailman so it could be used for other Python projects
# requiring file locking. See the __main__ section at the bottom of the file
# for unit testing.
import os
import socket
import time
import errno
import random
from stat import ST_NLINK, ST_MTIME
# Units are floating-point seconds.
DEFAULT_LOCK_LIFETIME = 15
# Allowable a bit of clock skew
CLOCK_SLOP = 10
# Figure out what logfile to use. This is different depending on whether
# we're running in a Mailman context or not.
_logfile = None
def _create_logfile():
try:
from Mailman.Logging.StampedLogger import StampedLogger
return StampedLogger('locks')
except ImportError:
# not running inside Mailman
import tempfile
dir = os.path.split(tempfile.mktemp())[0]
path = os.path.join(dir, 'LockFile.log')
# open in line-buffered mode
class SimpleUserFile:
def __init__(self, path):
self.__fp = open(path, 'a', 1)
self.__prefix = '(%d) ' % os.getpid()
def write(self, msg):
now = '%.3f' % time.time()
self.__fp.write(self.__prefix + now + ' ' + msg)
return SimpleUserFile(path)
# Exceptions that can be raised by this module
class LockError(Exception):
"""Base class for all exceptions in this module."""
class AlreadyLockedError(LockError):
"""An attempt is made to lock an already locked object."""
class NotLockedError(LockError):
"""An attempt is made to unlock an object that isn't locked."""
class TimeOutError(LockError):
"""The timeout interval elapsed before the lock succeeded."""
class LockFile:
"""A portable way to lock resources by way of the file system.
This class supports the following methods:
__init__(lockfile[, lifetime[, withlogging]]):
Create the resource lock using lockfile as the global lock file. Each
process laying claim to this resource lock will create their own
temporary lock files based on the path specified by lockfile.
Optional lifetime is the number of seconds the process expects to hold
the lock. Optional withlogging, when true, turns on lockfile logging
(see the module docstring for details).
set_lifetime(lifetime):
Set a new lock lifetime. This takes affect the next time the file is
locked, but does not refresh a locked file.
get_lifetime():
Return the lock's lifetime.
refresh([newlifetime[, unconditionally]]):
Refreshes the lifetime of a locked file. Use this if you realize that
you need to keep a resource locked longer than you thought. With
optional newlifetime, set the lock's lifetime. Raises NotLockedError
if the lock is not set, unless optional unconditionally flag is set to
true.
lock([timeout]):
Acquire the lock. This blocks until the lock is acquired unless
optional timeout is greater than 0, in which case, a TimeOutError is
raised when timeout number of seconds (or possibly more) expires
without lock acquisition. Raises AlreadyLockedError if the lock is
already set.
unlock([unconditionally]):
Relinquishes the lock. Raises a NotLockedError if the lock is not
set, unless optional unconditionally is true.
locked():
Return 1 if the lock is set, otherwise 0. To avoid race conditions,
this refreshes the lock (on set locks).
"""
def __init__(self, lockfile,
lifetime=DEFAULT_LOCK_LIFETIME,
withlogging=0):
"""Create the resource lock using lockfile as the global lock file.
Each process laying claim to this resource lock will create their own
temporary lock files based on the path specified by lockfile.
Optional lifetime is the number of seconds the process expects to hold
the lock. Optional withlogging, when true, turns on lockfile logging
(see the module docstring for details).
"""
self.__lockfile = lockfile
self.__lifetime = lifetime
self.__tmpfname = '%s.%s.%d' % (
lockfile, socket.gethostname(), os.getpid())
self.__withlogging = withlogging
self.__logprefix = os.path.split(self.__lockfile)[1]
def set_lifetime(self, lifetime):
"""Set a new lock lifetime.
This takes affect the next time the file is locked, but does not
refresh a locked file.
"""
self.__lifetime = lifetime
def get_lifetime(self):
"""Return the lock's lifetime."""
return self.__lifetime
def refresh(self, newlifetime=None, unconditionally=0):
"""Refreshes the lifetime of a locked file.
Use this if you realize that you need to keep a resource locked longer
than you thought. With optional newlifetime, set the lock's lifetime.
Raises NotLockedError if the lock is not set, unless optional
unconditionally flag is set to true.
"""
if newlifetime is not None:
self.set_lifetime(newlifetime)
# Do we have the lock? As a side effect, this refreshes the lock!
if not self.locked() and not unconditionally:
raise NotLockedError
def lock(self, timeout=0):
"""Acquire the lock.
This blocks until the lock is acquired unless optional timeout is
greater than 0, in which case, a TimeOutError is raised when timeout
number of seconds (or possibly more) expires without lock acquisition.
Raises AlreadyLockedError if the lock is already set.
"""
if timeout:
timeout_time = time.time() + timeout
# Make sure my temp lockfile exists, and that its contents are
# up-to-date (e.g. the temp file name, and the lock lifetime).
self.__write()
self.__touch()
self.__writelog('laying claim')
# for quieting the logging output
loopcount = -1
while 1:
loopcount = loopcount + 1
# Create the hard link and test for exactly 2 links to the file
try:
os.link(self.__tmpfname, self.__lockfile)
# If we got here, we know we know we got the lock, and never
# had it before, so we're done. Just touch it again for the
# fun of it.
self.__writelog('got the lock')
self.__touch()
break
except OSError, e:
# The link failed for some reason, possibly because someone
# else already has the lock (i.e. we got an EEXIST), or for
# some other bizarre reason.
if e.errno == errno.ENOENT:
# TBD: in some Linux environments, it is possible to get
# an ENOENT, which is truly strange, because this means
# that self.__tmpfname doesn't exist at the time of the
# os.link(), but self.__write() is supposed to guarantee
# that this happens! I don't honestly know why this
# happens, but for now we just say we didn't acquire the
# lock, and try again next time.
pass
elif e.errno <> errno.EEXIST:
# Something very bizarre happened. Clean up our state and
# pass the error on up.
self.__writelog('unexpected link error: %s' % e)
os.unlink(self.__tmpfname)
raise
elif self.__linkcount() <> 2:
# Somebody's messin' with us! Log this, and try again
# later. TBD: should we raise an exception?
self.__writelog('unexpected linkcount <> 2: %d' %
self.__linkcount())
elif self.__read() == self.__tmpfname:
# It was us that already had the link.
self.__writelog('already locked')
os.unlink(self.__tmpfname)
raise AlreadyLockedError
# otherwise, someone else has the lock
pass
# We did not acquire the lock, because someone else already has
# it. Have we timed out in our quest for the lock?
if timeout and timeout_time < time.time():
os.unlink(self.__tmpfname)
self.__writelog('timed out')
raise TimeOutError
# Okay, we haven't timed out, but we didn't get the lock. Let's
# find if the lock lifetime has expired.
if time.time() > self.__releasetime() + CLOCK_SLOP:
# Yes, so break the lock.
self.__break()
self.__writelog('lifetime has expired, breaking')
# Okay, someone else has the lock, our claim hasn't timed out yet,
# and the expected lock lifetime hasn't expired yet. So let's
# wait a while for the owner of the lock to give it up.
elif not loopcount % 100:
self.__writelog('waiting for claim')
self.__sleep()
def unlock(self, unconditionally=0):
"""Unlock the lock.
If we don't already own the lock (either because of unbalanced unlock
calls, or because the lock was stolen out from under us), raise a
NotLockedError, unless optional `unconditional' is true.
"""
islocked = 0
try:
islocked = self.locked()
except OSError, e:
if e.errno <> errno.ENOENT: raise
if not islocked and not unconditionally:
raise NotLockedError
# Remove our tempfile
try:
os.unlink(self.__tmpfname)
except OSError, e:
if e.errno <> errno.ENOENT: raise
# If we owned the lock, remove the global file, relinquishing it.
if islocked:
try:
os.unlink(self.__lockfile)
except OSError, e:
if e.errno <> errno.ENOENT: raise
self.__writelog('unlocked')
def locked(self):
"""Returns 1 if we own the lock, 0 if we do not.
Checking the status of the lockfile resets the lock's lifetime, which
helps avoid race conditions during the lock status test.
"""
# Discourage breaking the lock for a while.
self.__touch()
# TBD: can the link count ever be > 2?
if self.__linkcount() <> 2:
return 0
return self.__read() == self.__tmpfname
def finalize(self):
self.unlock(unconditionally=1)
def __del__(self):
self.finalize()
#
# Private interface
#
def __writelog(self, msg):
global _logfile
if self.__withlogging:
if not _logfile:
_logfile = _create_logfile()
_logfile.write('%s %s\n' % (self.__logprefix, msg))
def __write(self):
# Make sure it's group writable
oldmask = os.umask(002)
try:
fp = open(self.__tmpfname, 'w')
fp.write(self.__tmpfname)
fp.close()
finally:
os.umask(oldmask)
def __read(self):
try:
fp = open(self.__lockfile)
filename = fp.read()
fp.close()
return filename
except (OSError, IOError), e:
if e.errno <> errno.ENOENT: raise
return None
def __touch(self, filename=None):
t = time.time() + self.__lifetime
try:
# TBD: We probably don't need to modify atime, but this is easier.
os.utime(filename or self.__tmpfname, (t, t))
except OSError, e:
if e.errno <> errno.ENOENT: raise
def __releasetime(self):
try:
return os.stat(self.__lockfile)[ST_MTIME]
except OSError, e:
if e.errno <> errno.ENOENT: raise
return -1
def __linkcount(self):
try:
return os.stat(self.__lockfile)[ST_NLINK]
except OSError, e:
if e.errno <> errno.ENOENT: raise
return -1
def __break(self):
# First, touch the global lock file so no other process will try to
# break the lock while we're doing it. Specifically, this avoids the
# race condition where we've decided to break the lock at the same
# time someone else has, but between the time we made this decision
# and the time we read the winner out of the global lock file, they've
# gone ahead and claimed the lock.
self.__touch(self.__lockfile)
# Try to remove the old winner's temp file, since we're assuming the
# winner process has hung or died. Don't worry too much if we can't
# unlink their temp file -- this doesn't break the locking algorithm,
# but will leave temp file turds laying around, a minor inconvenience.
try:
winner = self.__read()
if winner:
os.unlink(winner)
except OSError, e:
if e.errno <> errno.ENOENT: raise
# Now remove the global lockfile, which actually breaks the lock.
try:
os.unlink(self.__lockfile)
except OSError, e:
if e.errno <> errno.ENOENT: raise
def __sleep(self):
interval = random.random() * 2.0 + 0.01
time.sleep(interval)
# Unit test framework
def _dochild():
prefix = '[%d]' % os.getpid()
# Create somewhere between 1 and 1000 locks
lockfile = LockFile('/tmp/LockTest', withlogging=1, lifetime=120)
# Use a lock lifetime of between 1 and 15 seconds. Under normal
# situations, Mailman's usage patterns (untested) shouldn't be much longer
# than this.
workinterval = 5 * random.random()
hitwait = 20 * random.random()
print prefix, 'workinterval:', workinterval
islocked = 0
t0 = 0
t1 = 0
t2 = 0
try:
try:
t0 = time.time()
print prefix, 'acquiring...'
lockfile.lock()
print prefix, 'acquired...'
islocked = 1
except TimeOutError:
print prefix, 'timed out'
else:
t1 = time.time()
print prefix, 'acquisition time:', t1-t0, 'seconds'
time.sleep(workinterval)
finally:
if islocked:
try:
lockfile.unlock()
t2 = time.time()
print prefix, 'lock hold time:', t2-t1, 'seconds'
except NotLockedError:
print prefix, 'lock was broken'
# wait for next web hit
print prefix, 'webhit sleep:', hitwait
time.sleep(hitwait)
def _onetest():
loopcount = random.randint(1, 100)
for i in range(loopcount):
pid = os.fork()
if pid:
# parent, wait for child to exit
pid, status = os.waitpid(pid, 0)
else:
# child
try:
_dochild()
except KeyboardInterrupt:
pass
os._exit(0)
def _reap(kids):
if not kids:
return
pid, status = os.waitpid(-1, os.WNOHANG)
if pid <> 0:
del kids[pid]
def _test(numtests):
kids = {}
for i in range(numtests):
pid = os.fork()
if pid:
# parent
kids[pid] = pid
else:
# child
try:
import sha
random.seed(sha.new(`os.getpid()`+`time.time()`).hexdigest())
_onetest()
except KeyboardInterrupt:
pass
os._exit(0)
# slightly randomize each kid's seed
while kids:
_reap(kids)
if __name__ == '__main__':
import sys
import random
_test(int(sys.argv[1]))
From jarrell@vt.edu Mon May 1 19:17:43 2000
From: jarrell@vt.edu (Ron Jarrell)
Date: Mon, 01 May 2000 14:17:43 -0400
Subject: [Mailman-Developers] New LockFile.py
In-Reply-To: <14605.49704.849479.12542@anthem.cnri.reston.va.us>
Message-ID: <4.3.1.2.20000501141436.00bdbf00@vtserf.cc.vt.edu>
--=====================_257564536==_.ALT
Content-Type: text/plain; charset="us-ascii"
At 01:43 PM 5/1/00 -0400, Barry Warsaw wrote:
>The one questionable aspect of the new LockFile.py is that it uses the
>mtime of the file as the lock's lifetime. This works great for
>avoiding race conditions but means that Mailman is setting mtime's of
>the files to some time in the future. Is anybody aware of OSes where
>this will be a problem? Linux and Solaris both seem to stay happy.
The things I can think of:
1) This makes mailman very sensitive to time synchonization problems
in environments with NFS mounted directories (possibly more a problem
with mailman than many others since it's so easy to just run it out of ~mailman
as a regular user).
2) Setting mtime in the future will probably piss off fsck; which in environments
with multiple systadmins, or the mailman person isn't a sysadmin, could be
horribly confusing.
Both can probably be addressed by adding warnings to the readme and/or
install files.
--=====================_257564536==_.ALT
Content-Type: text/html; charset="us-ascii"
At 01:43 PM 5/1/00 -0400, Barry Warsaw wrote:
The one questionable aspect of the new
LockFile.py is that it uses the
mtime of the file as the lock's lifetime. This works great
for
avoiding race conditions but means that Mailman is setting mtime's
of
the files to some time in the future. Is anybody aware of OSes
where
this will be a problem? Linux and Solaris both seem to stay
happy.
The things I can think of:
1) This makes mailman very sensitive to time synchonization
problems
in environments with NFS mounted directories (possibly more a
problem
with mailman than many others since it's so easy to just run it out of
~mailman
as a regular user).
2) Setting mtime in the future will probably piss off fsck; which in
environments
with multiple systadmins, or the mailman person isn't a sysadmin, could
be
horribly confusing.
Both can probably be addressed by adding warnings to the readme
and/or
install files.
--=====================_257564536==_.ALT--
From bwarsaw@python.org Mon May 1 19:49:22 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Mon, 1 May 2000 14:49:22 -0400 (EDT)
Subject: [Mailman-Developers] New LockFile.py
References: <14605.49704.849479.12542@anthem.cnri.reston.va.us>
<4.3.1.2.20000501141436.00bdbf00@vtserf.cc.vt.edu>
Message-ID: <14605.53682.538244.569975@anthem.cnri.reston.va.us>
>>>>> "RJ" == Ron Jarrell writes:
RJ> 1) This makes mailman very sensitive to time synchonization
RJ> problems in environments with NFS mounted directories
RJ> (possibly more a problem with mailman than many others since
RJ> it's so easy to just run it out of ~mailman as a regular
RJ> user).
True, but I think in the face of lock breakage, you're going to be
sensitive to time sync anyway. I've also added a CLOCK_SLOP variable
which can be tweaked if necessary.
RJ> 2) Setting mtime in the future will probably piss off fsck;
RJ> which in environments with multiple systadmins, or the mailman
RJ> person isn't a sysadmin, could be horribly confusing.
Hmm, hadn't though of that. Hopefully, I've made the termination
cases sufficiently robust so that those lock files won't hang around
long enough to get fsck'd.
RJ> Both can probably be addressed by adding warnings to the
RJ> readme and/or install files.
Good points both; I'll do this. Thanks.
-Barry
From jarrell@vt.edu Mon May 1 21:03:07 2000
From: jarrell@vt.edu (Ron Jarrell)
Date: Mon, 01 May 2000 16:03:07 -0400
Subject: [Mailman-Developers] New LockFile.py
In-Reply-To: <14605.53682.538244.569975@anthem.cnri.reston.va.us>
References: <14605.49704.849479.12542@anthem.cnri.reston.va.us>
<4.3.1.2.20000501141436.00bdbf00@vtserf.cc.vt.edu>
Message-ID: <4.3.1.2.20000501160238.05080240@vtserf.cc.vt.edu>
--=====================_263397147==_.ALT
Content-Type: text/plain; charset="us-ascii"
At 02:49 PM 5/1/00 -0400, bwarsaw@python.org wrote:
> RJ> 2) Setting mtime in the future will probably piss off fsck;
> RJ> which in environments with multiple systadmins, or the mailman
> RJ> person isn't a sysadmin, could be horribly confusing.
>
>Hmm, hadn't though of that. Hopefully, I've made the termination
>cases sufficiently robust so that those lock files won't hang around
>long enough to get fsck'd.
Unless the machine crashed, which is why you're fscking the file
system :-).
--=====================_263397147==_.ALT
Content-Type: text/html; charset="us-ascii"
At 02:49 PM 5/1/00 -0400, bwarsaw@python.org wrote:
RJ> 2) Setting mtime in
the future will probably piss off fsck;
RJ> which in environments with multiple systadmins,
or the mailman
RJ> person isn't a sysadmin, could be horribly
confusing.
Hmm, hadn't though of that. Hopefully, I've made the
termination
cases sufficiently robust so that those lock files won't hang
around
long enough to get fsck'd.
Unless the machine crashed, which is why you're fscking the file
system :-).
--=====================_263397147==_.ALT--
From bwarsaw@python.org Mon May 1 21:08:28 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Mon, 1 May 2000 16:08:28 -0400 (EDT)
Subject: [Mailman-Developers] New LockFile.py
References: <14605.49704.849479.12542@anthem.cnri.reston.va.us>
<4.3.1.2.20000501141436.00bdbf00@vtserf.cc.vt.edu>
<4.3.1.2.20000501160238.05080240@vtserf.cc.vt.edu>
Message-ID: <14605.58428.579299.868143@anthem.cnri.reston.va.us>
>>>>> "RJ" == Ron Jarrell writes:
RJ> Unless the machine crashed, which is why you're fscking the
RJ> file system :-).
True, true.
From Dan Mick Tue May 2 03:36:24 2000
From: Dan Mick (Dan Mick)
Date: Mon, 1 May 2000 19:36:24 -0700 (PDT)
Subject: [Mailman-Developers] New LockFile.py
Message-ID: <200005020236.TAA11021@utopia.west.sun.com>
> >>>>> "RJ" == Ron Jarrell writes:
>
> RJ> Unless the machine crashed, which is why you're fscking the
> RJ> file system :-).
>
> True, true.
Setting dates in the future seems like a really bad idea to me...
From dick@acm.org Tue May 2 09:42:06 2000
From: dick@acm.org (Dick Porter)
Date: Tue, 2 May 2000 09:42:06 +0100
Subject: [Mailman-Developers] New LockFile.py
In-Reply-To: <200005020236.TAA11021@utopia.west.sun.com>; from Dan.Mick@West.Sun.COM on Mon, May 01, 2000 at 07:36:24PM -0700
References: <200005020236.TAA11021@utopia.west.sun.com>
Message-ID: <20000502094206.E5670@dick.i2it.co.uk>
On Mon, May 01, 2000 at 07:36:24PM -0700, Dan Mick wrote:
>
> > >>>>> "RJ" == Ron Jarrell writes:
> >
> > RJ> Unless the machine crashed, which is why you're fscking the
> > RJ> file system :-).
> >
> > True, true.
>
> Setting dates in the future seems like a really bad idea to me...
Postfix uses this technique to manage its deferred queue. I haven't seen
any problems due to this reported on the postfix list.
- Dick
From doko@cs.tu-berlin.de Tue May 2 09:50:11 2000
From: doko@cs.tu-berlin.de (Matthias Klose)
Date: Tue, 2 May 2000 10:50:11 +0200 (MET DST)
Subject: [Mailman-Developers] using real user names for list members
Message-ID: <14606.38595.645110.766375@gargle.gargle.HOWL>
Is it currently possible/or planned to use names like
Real Name
email address (Real name)
as the name of a subscriber? For authentification the email address
should be sufficeint.
From Nigel.Metheringham@VData.co.uk Tue May 2 09:54:37 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Tue, 02 May 2000 09:54:37 +0100
Subject: [Mailman-Developers] change the envelope sender with
Sendmail.py?
In-Reply-To: Message from Brian Edmonds
of "30 Apr 2000 14:22:44 PDT." <37em7n472z.fsf@lios.gweep.bc.ca>
Message-ID:
brian@gweep.bc.ca said:
> I don't know if this is also a problem in the direct SMTP module. I'm
> using Sendmail.py because my MTA is sendmail, but I'm using postfix in
> outgoing only configuration for the list delivery since mailman was
> getting sendmail to send each message as one huge batch of addresses.
The Sendmail.py module has a number of other problems, and I would
strongly suggest that it not be used at present - the name is a
reference to the calling interface used rather than necessarily the MTA.
DirectSMTP works fine with sendmail and all other MTAs I know of.
The handing off of addresses in one blob is a simplification of the MTA
handling logic for Mailman 2. A decent MTA should be able to handle
having all the addresses in one chunk and make whatever efficiency
saving are appropriate... however different MTAs will have different
trade offs for this sort of operation - list handling is actually
rather different in terms of message sizes, recipients etc than normal
mail and also has slightly different requirements.
Nigel.
--
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]
From brown9@niehs.nih.gov Tue May 2 15:41:57 2000
From: brown9@niehs.nih.gov (Lance A. Brown)
Date: Tue, 02 May 2000 10:41:57 -0400
Subject: [Mailman-Developers] Re: New LockFile.py
In-Reply-To: <20000502094206.E5670@dick.i2it.co.uk>
References: <200005020236.TAA11021@utopia.west.sun.com>
<20000502094206.E5670@dick.i2it.co.uk>
Message-ID: <756.957278517@splat.niehs.nih.gov>
Dick Poerter wrote:
> > Setting dates in the future seems like a really bad idea to me...
>
> Postfix uses this technique to manage its deferred queue. I haven't seen
> any problems due to this reported on the postfix list.
The new versions of Big Brother also sets timestamps on files in the future. There have been no reports of problems with this on the BB lists.
--[Lance]
From bwarsaw@python.org Tue May 2 16:12:05 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Tue, 2 May 2000 11:12:05 -0400 (EDT)
Subject: [Mailman-Developers] New LockFile.py
References: <200005020236.TAA11021@utopia.west.sun.com>
Message-ID: <14606.61509.407756.744314@anthem.cnri.reston.va.us>
>>>>> "DM" == Dan Mick writes:
>> "RJ" == Ron Jarrell writes:
>> RJ> Unless the machine crashed, which is why you're fscking
>> the RJ> file system :-). True, true.
DM> Setting dates in the future seems like a really bad idea to
DM> me...
Can you elaborate? Are you aware of specific problems?
e2fsck on Linux doesn't seem to care one wit about files with future
mtimes. I haven't tried Solaris.
-Barry
From bolen@hcs.harvard.edu Tue May 2 18:23:17 2000
From: bolen@hcs.harvard.edu (britt)
Date: Tue, 2 May 2000 13:23:17 -0400 (EDT)
Subject: [Mailman-Developers] list membership privacy
In-Reply-To: <1803081.3165926136@sdhcp5.emji.net>
Message-ID:
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--0-346115632-957288197=:6986
Content-Type: TEXT/PLAIN; charset=US-ASCII
I've got a couple of patches to Mailman 2.0b2 that reduces the number of
ways that someone can prob the membership of a list. It removes all
errors from the options and subscribe pages that mention foo@bar is/is not
on this list, and instead always say "bad password".
You can still probe by trying to subscribe a person. Fixing this is more
work, so I haven't done it yet...
In short it improves member privacy to a level better than majordomo.
B
-----------------------------------------------------------------------
Britt Bolen britt@bolen.com britt.bolen.com
--0-346115632-957288197=:6986
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="privacy.patch"
Content-Transfer-Encoding: BASE64
Content-ID:
Content-Description:
Content-Disposition: attachment; filename="privacy.patch"
ZGlmZiAtYyBtYWlsbWFuLTIuMGJldGEyL01haWxtYW4vQ2dpL2hhbmRsZV9v
cHRzLnB5IG1haWxtYW4tMi4wYmV0YTItbG9jYWxjaGFuZ2VzL01haWxtYW4v
Q2dpL2hhbmRsZV9vcHRzLnB5DQoqKiogbWFpbG1hbi0yLjBiZXRhMi9NYWls
bWFuL0NnaS9oYW5kbGVfb3B0cy5weQlUdWUgQXByICA0IDE5OjQyOjE4IDIw
MDANCi0tLSBtYWlsbWFuLTIuMGJldGEyLWxvY2FsY2hhbmdlcy9NYWlsbWFu
L0NnaS9oYW5kbGVfb3B0cy5weQlUdWUgTWF5ICAyIDEzOjA2OjA1IDIwMDAN
CioqKioqKioqKioqKioqKg0KKioqIDkwLDk2ICoqKioNCiAgDQogICAgICBp
ZiBub3QgVXRpbHMuRmluZE1hdGNoaW5nQWRkcmVzc2VzKHVzZXIsIG1saXN0
Lm1lbWJlcnMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIG1saXN0LmRpZ2VzdF9tZW1iZXJzKToNCiEgICAgICAgICBQcmlu
dFJlc3VsdHMobWxpc3QsIG9wZXJhdGlvbiwgZG9jLCAiJXMgbm90IGEgbWVt
YmVyITxwPiIgJSB1c2VyKQ0KICANCiAgICAgIGlmIGZvcm0uaGFzX2tleSgi
dW5zdWIiKToNCiAgICAgICAgICBvcGVyYXRpb24gPSAiVW5zdWJzY3JpYmUi
DQotLS0gOTAsOTYgLS0tLQ0KICANCiAgICAgIGlmIG5vdCBVdGlscy5GaW5k
TWF0Y2hpbmdBZGRyZXNzZXModXNlciwgbWxpc3QubWVtYmVycywNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWxpc3QuZGln
ZXN0X21lbWJlcnMpOg0KISAgICAgICAgIFByaW50UmVzdWx0cyhtbGlzdCwg
b3BlcmF0aW9uLCBkb2MsICJUaGF0IHBhc3N3b3JkIHdhcyBpbmNvcnJlY3Qu
PHA+IikNCiAgDQogICAgICBpZiBmb3JtLmhhc19rZXkoInVuc3ViIik6DQog
ICAgICAgICAgb3BlcmF0aW9uID0gIlVuc3Vic2NyaWJlIg0KZGlmZiAtYyBt
YWlsbWFuLTIuMGJldGEyL01haWxtYW4vQ2dpL29wdGlvbnMucHkgbWFpbG1h
bi0yLjBiZXRhMi1sb2NhbGNoYW5nZXMvTWFpbG1hbi9DZ2kvb3B0aW9ucy5w
eQ0KKioqIG1haWxtYW4tMi4wYmV0YTIvTWFpbG1hbi9DZ2kvb3B0aW9ucy5w
eQlUdWUgQXByICA0IDE5OjEyOjUwIDIwMDANCi0tLSBtYWlsbWFuLTIuMGJl
dGEyLWxvY2FsY2hhbmdlcy9NYWlsbWFuL0NnaS9vcHRpb25zLnB5CVR1ZSBN
YXkgIDIgMTM6MDU6MjMgMjAwMA0KKioqKioqKioqKioqKioqDQoqKiogNjYs
OTIgKioqKg0KICAgICAgICAgIHJldHVybg0KICANCiAgICAgICMgU2FuaXR5
IGNoZWNrIHRoZSB1c2VyDQogICAgICB1c2VyID0gVXRpbHMuTENEb21haW4o
dXNlcikNCiAgICAgIGlmIG5vdCBtbGlzdC5tZW1iZXJzLmhhc19rZXkodXNl
cikgYW5kIFwNCiAgICAgICAgICAgICAgbm90IG1saXN0LmRpZ2VzdF9tZW1i
ZXJzLmhhc19rZXkodXNlcik6DQohICAgICAgICAgIyB0aGVuDQohICAgICAg
ICAgZG9jLkFkZEl0ZW0oSGVhZGVyKDIsICJFcnJvciIpKQ0KISAgICAgICAg
IGRvYy5BZGRJdGVtKEJvbGQoIiVzOiBObyBzdWNoIG1lbWJlciAlcy4iICUg
KGxpc3RuYW1lLCBgdXNlcmApKSkNCiEgICAgICAgICBkb2MuQWRkSXRlbSht
bGlzdC5HZXRNYWlsbWFuRm9vdGVyKCkpDQohICAgICAgICAgcHJpbnQgZG9j
LkZvcm1hdCgpDQohICAgICAgICAgcmV0dXJuDQogIA0KICAgICAgIyBmaW5k
IHRoZSBjYXNlIHByZXNlcnZlZCBlbWFpbCBhZGRyZXNzICh0aGUgb25lIHRo
ZSB1c2VyIHN1YnNjcmliZWQgd2l0aCkNCiEgICAgIGxjdXNlciA9IG1saXN0
LkZpbmRVc2VyKHVzZXIpDQohICAgICBjcHVzZXIgPSBtbGlzdC5HZXRVc2Vy
U3Vic2NyaWJlZEFkZHJlc3MobGN1c2VyKQ0KISAgICAgaWYgbGN1c2VyID09
IGNwdXNlcjoNCiEgICAgICAgICBjcHVzZXIgPSBOb25lDQohICAgICBpZiBt
bGlzdC5vYnNjdXJlX2FkZHJlc3NlczoNCiEgICAgICAgICBwcmVzZW50YWJs
ZV91c2VyID0gVXRpbHMuT2JzY3VyZUVtYWlsKHVzZXIsIGZvcl90ZXh0PTEp
DQohICAgICAgICAgaWYgY3B1c2VyIGlzIG5vdCBOb25lOg0KISAgICAgICAg
ICAgICBjcHVzZXIgPSBVdGlscy5PYnNjdXJlRW1haWwoY3B1c2VyLCBmb3Jf
dGV4dD0xKQ0KICAgICAgZWxzZToNCiEgICAgICAgICBwcmVzZW50YWJsZV91
c2VyID0gdXNlcg0KICANCiAgICAgICMgRG8gcmVwbGFjZW1lbnRzDQogICAg
ICByZXBsYWNlbWVudHMgPSBtbGlzdC5HZXRTdGFuZGFyZFJlcGxhY2VtZW50
cygpDQotLS0gNjYsOTYgLS0tLQ0KICAgICAgICAgIHJldHVybg0KICANCiAg
ICAgICMgU2FuaXR5IGNoZWNrIHRoZSB1c2VyDQorICAgICB1bmtub3duVXNl
ciA9IDAgDQogICAgICB1c2VyID0gVXRpbHMuTENEb21haW4odXNlcikNCiAg
ICAgIGlmIG5vdCBtbGlzdC5tZW1iZXJzLmhhc19rZXkodXNlcikgYW5kIFwN
CiAgICAgICAgICAgICAgbm90IG1saXN0LmRpZ2VzdF9tZW1iZXJzLmhhc19r
ZXkodXNlcik6DQohICAgICAgICAgdW5rbm93blVzZXIgPSAxDQogIA0KICAg
ICAgIyBmaW5kIHRoZSBjYXNlIHByZXNlcnZlZCBlbWFpbCBhZGRyZXNzICh0
aGUgb25lIHRoZSB1c2VyIHN1YnNjcmliZWQgd2l0aCkNCiEgICAgIA0KISAg
ICAgaWYgdW5rbm93blVzZXIgPT0gMDoNCiEgCWxjdXNlciA9IG1saXN0LkZp
bmRVc2VyKHVzZXIpDQohIAljcHVzZXIgPSBtbGlzdC5HZXRVc2VyU3Vic2Ny
aWJlZEFkZHJlc3MobGN1c2VyKQ0KISAJaWYgbGN1c2VyID09IGNwdXNlcjoN
CiEgCSAgICBjcHVzZXIgPSBOb25lDQohIAlpZiBtbGlzdC5vYnNjdXJlX2Fk
ZHJlc3NlczoNCiEgCSAgICBwcmVzZW50YWJsZV91c2VyID0gVXRpbHMuT2Jz
Y3VyZUVtYWlsKHVzZXIsIGZvcl90ZXh0PTEpDQohIAkgICAgaWYgY3B1c2Vy
IGlzIG5vdCBOb25lOg0KISAgICAgICAgICAgICAgICBjcHVzZXIgPSBVdGls
cy5PYnNjdXJlRW1haWwoY3B1c2VyLCBmb3JfdGV4dD0xKQ0KISAgICAgICAg
IGVsc2U6DQohIAkgICAgcHJlc2VudGFibGVfdXNlciA9IHVzZXINCiAgICAg
IGVsc2U6DQohICAgICAgICAgbHVzZXIgPSAibHVzZXJAYmF6Ig0KISAJY3B1
c2VyID0gImNwdXNlckBiYXoiDQohIAlwcmVzZW50YWJsZV91c2VyID0gInBy
ZXNlbnRhYmxlX3VzZXIiDQohIAlwcmVzZW50YWJsZV91c2VyID0gVXRpbHMu
T2JzY3VyZUVtYWlsKHVzZXIsIGZvcl90ZXh0PTEpDQohICAgICAgICAgY3B1
c2VyID0gVXRpbHMuT2JzY3VyZUVtYWlsKHVzZXIsIGZvcl90ZXh0PTEpDQog
IA0KICAgICAgIyBEbyByZXBsYWNlbWVudHMNCiAgICAgIHJlcGxhY2VtZW50
cyA9IG1saXN0LkdldFN0YW5kYXJkUmVwbGFjZW1lbnRzKCkNCioqKioqKioq
KioqKioqKg0KKioqIDExNSwxMjAgKioqKg0KLS0tIDExOSwxMzAgLS0tLQ0K
ICAgICAgICAgIG1saXN0LkZvcm1hdE9wdGlvbkJ1dHRvbihtbV9jZmcuQ29u
Y2VhbFN1YnNjcmlwdGlvbiwgMCwgdXNlcikpDQogICAgICByZXBsYWNlbWVu
dHNbJzxtbS1oaWRlLXN1YnNjcmlwdGlvbi1idXR0b24+J10gPSBtbGlzdC5G
b3JtYXRPcHRpb25CdXR0b24oDQogICAgICAgICAgbW1fY2ZnLkNvbmNlYWxT
dWJzY3JpcHRpb24sIDEsIHVzZXIpDQorICAgICBpZiB1bmtub3duVXNlciA9
PSAxOg0KKyAgICAgICAgIHJlcGxhY2VtZW50c1snPG1tLXB1YmxpYy1zdWJz
Y3JpcHRpb24tYnV0dG9uPiddID0gKA0KKyAgICAgICAgICAgIG1saXN0LkZv
cm1hdE9wdGlvbkJ1dHRvbihtbV9jZmcuQ29uY2VhbFN1YnNjcmlwdGlvbiwg
MSwgdXNlcikpDQorICAgICAgICAgcmVwbGFjZW1lbnRzWyc8bW0taGlkZS1z
dWJzY3JpcHRpb24tYnV0dG9uPiddID0gKA0KKyAgICAgICAgICAgIG1saXN0
LkZvcm1hdE9wdGlvbkJ1dHRvbihtbV9jZmcuQ29uY2VhbFN1YnNjcmlwdGlv
biwgMCwgdXNlcikpDQorICAgICAgICAgDQogICAgICByZXBsYWNlbWVudHNb
JzxtbS1kaWdlc3Qtc3VibWl0PiddID0gbWxpc3QuRm9ybWF0QnV0dG9uKA0K
ICAgICAgICAgICdzZXRkaWdlc3QnLCAnU3VibWl0IE15IENoYW5nZXMnKQ0K
ICAgICAgcmVwbGFjZW1lbnRzWyc8bW0tdW5zdWJzY3JpYmUtYnV0dG9uPidd
ID0gKA0KZGlmZiAtYyBtYWlsbWFuLTIuMGJldGEyL01haWxtYW4vQ2dpL3N1
YnNjcmliZS5weSBtYWlsbWFuLTIuMGJldGEyLWxvY2FsY2hhbmdlcy9NYWls
bWFuL0NnaS9zdWJzY3JpYmUucHkNCioqKiBtYWlsbWFuLTIuMGJldGEyL01h
aWxtYW4vQ2dpL3N1YnNjcmliZS5weQlUdWUgQXByICA0IDE5OjM4OjI1IDIw
MDANCi0tLSBtYWlsbWFuLTIuMGJldGEyLWxvY2FsY2hhbmdlcy9NYWlsbWFu
L0NnaS9zdWJzY3JpYmUucHkJVHVlIE1heSAgMiAxMzoxODoyOCAyMDAwDQoq
KioqKioqKioqKioqKioNCioqKiAxMDAsMTExICoqKioNCiAgICAgICAgICBh
ZGRyID0gZm9ybVsnaW5mbyddLnZhbHVlDQogICAgICAgICAgbWVtYmVyID0g
bWxpc3QuRmluZFVzZXIoYWRkcikNCiAgICAgICAgICBpZiBub3QgbWVtYmVy
Og0KISAgICAgICAgICAgICBkb2MuQWRkSXRlbShIZWFkZXIoMiwgIkVycm9y
IikpDQohICAgICAgICAgICAgIGRvYy5BZGRJdGVtKEJvbGQoIiVzIGhhcyBu
byBzdWJzY3JpYmVkIGFkZHIgPGk+JXM8L2k+LiINCiEgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAlIChtbGlzdC5yZWFsX25hbWUsIGFkZHIpKSkN
CiEgICAgICAgICAgICAgZG9jLkFkZEl0ZW0obWxpc3QuR2V0TWFpbG1hbkZv
b3RlcigpKQ0KISAgICAgICAgICAgICBwcmludCBkb2MuRm9ybWF0KGJnY29s
b3I9IiNmZmZmZmYiKQ0KISAgICAgICAgICAgICByZXR1cm4NCiAgDQogICAg
ICAgICAgY2FsbF9zY3JpcHQobWxpc3QsIG1lbWJlciwgJ29wdGlvbnMnKQ0K
ICAgICAgICAgICMgc2hvdWxkIG5ldmVyIGdldCBoZXJlIQ0KLS0tIDEwMCwx
MDYgLS0tLQ0KICAgICAgICAgIGFkZHIgPSBmb3JtWydpbmZvJ10udmFsdWUN
CiAgICAgICAgICBtZW1iZXIgPSBtbGlzdC5GaW5kVXNlcihhZGRyKQ0KICAg
ICAgICAgIGlmIG5vdCBtZW1iZXI6DQohICAgICAgICAgICAgIG1lbWJlciA9
IGFkZHINCiAgDQogICAgICAgICAgY2FsbF9zY3JpcHQobWxpc3QsIG1lbWJl
ciwgJ29wdGlvbnMnKQ0KICAgICAgICAgICMgc2hvdWxkIG5ldmVyIGdldCBo
ZXJlIQ0K
--0-346115632-957288197=:6986--
From bwarsaw@python.org Tue May 2 19:15:50 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Tue, 2 May 2000 14:15:50 -0400 (EDT)
Subject: [Mailman-Developers] New LockFile.py
References: <200005020236.TAA11021@utopia.west.sun.com>
<14606.61509.407756.744314@anthem.cnri.reston.va.us>
Message-ID: <14607.6998.687565.999967@anthem.cnri.reston.va.us>
If you're using my new LockFile.py, you'll need this one fix. Because
the uid of the mail wrapper process probably doesn't equal the uid of
the cgi wrapper process, the os.utime() could fail with an EPERM.
Mailman could require both wrappers to run set-uid, but I don't think
this is necessary. The __touch() call in __break() just adds a small
comfort buffer, but I don't think it's essential that it succeed.
Here's the new LockFile.__break() method.
def __break(self):
# First, touch the global lock file so no other process will try to
# break the lock while we're doing it. Specifically, this avoids the
# race condition where we've decided to break the lock at the same
# time someone else has, but between the time we made this decision
# and the time we read the winner out of the global lock file, they've
# gone ahead and claimed the lock.
#
# TBD: This could fail if the process breaking the lock and the
# process that claimed the lock have different owners. We could solve
# this by set-uid'ing the CGI and mail wrappers, but I don't think
# it's that big a problem.
try:
self.__touch(self.__lockfile)
except OSError, e:
if e.errno <> errno.EPERM: raise
# Try to remove the old winner's temp file, since we're assuming the
# winner process has hung or died. Don't worry too much if we can't
# unlink their temp file -- this doesn't break the locking algorithm,
# but will leave temp file turds laying around, a minor inconvenience.
try:
winner = self.__read()
if winner:
os.unlink(winner)
except OSError, e:
if e.errno <> errno.ENOENT: raise
# Now remove the global lockfile, which actually breaks the lock.
try:
os.unlink(self.__lockfile)
except OSError, e:
if e.errno <> errno.ENOENT: raise
I'm going to give this another 24 hours on python.org and if it all
looks good, I'll commit the change.
-Barry
From bwarsaw@python.org Tue May 2 22:09:07 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Tue, 2 May 2000 17:09:07 -0400 (EDT)
Subject: [Mailman-Developers] race condition in locking ?
References: <20000202225346.B17313@xs4all.nl>
<20000204205630.A4871@miss-janet.com>
<20000204212243.B4871@miss-janet.com>
<20000204234757.A2826@xs4all.nl>
<20000205011507.A405@miss-janet.com>
<20000205164318.A15909@xs4all.nl>
<20000205205653.A4105@miss-janet.com>
<20000205232130.D23471@xs4all.nl>
<20000207204331.A444@miss-janet.com>
<20000207213143.B444@miss-janet.com>
<20000207225907.M19265@xs4all.nl>
Message-ID: <14607.17395.978323.325049@anthem.cnri.reston.va.us>
>>>>> "HM" == Harald Meland writes:
>> 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.
HM> Yup. This might produce a SIGPIPE, and/or the corresponding
HM> IOError EPIPE, and I've experienced that these didn't always
HM> get caught -- an attempt at a fix is near the end of run_main
HM> in http://www.uio.no/~hmeland/tmp/mailman-userdb/scripts/driver>,
HM> but I'm by no means positive that it's the Right fix.
I've done a bit of testing using Apache and both NS and MSIE. What I
did was add a big sleep in admin.py, in main(), just before the
finally at the bottom of the function. I added some debug prints so I
could see what was going on.
As near as I can tell, if I hit the browser's stop button after
entering that big sleep, the CGI process gets kill stone cold. It
never reach the finally clause, doesn't get a SIGPIPE, nothing. Since
I can't reproduce this, I'm not sure what the right thing to do is.
Harald, what webserver are you running?
-Barry
From bwarsaw@python.org Tue May 2 22:11:12 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Tue, 2 May 2000 17:11:12 -0400 (EDT)
Subject: [Mailman-Developers] lock lifetime
References: <20000322193038.A10212@miss-janet.com>
<14553.6564.572812.203295@anthem.cnri.reston.va.us>
<20000322211525.C10212@miss-janet.com>
<14553.14520.677676.569943@anthem.cnri.reston.va.us>
Message-ID: <14607.17520.410078.836232@anthem.cnri.reston.va.us>
>>>>> "HM" == Harald Meland writes:
HM> However, if my understanding of the problem is right, and this
HM> is the correct fix for it, I don't understand why the bare
HM> except: clause around the run_main() call in driver didn't
HM> kick in to produce a log entry...
Exactly. Does anybody have any more information they can provide
about this?
-Barry
From Dan.Mick@west.sun.com Tue May 2 23:15:00 2000
From: Dan.Mick@west.sun.com (Dan Mick)
Date: Tue, 02 May 2000 15:15:00 -0700
Subject: [Mailman-Developers] New LockFile.py
References: <200005020236.TAA11021@utopia.west.sun.com> <14606.61509.407756.744314@anthem.cnri.reston.va.us>
Message-ID: <390F5364.71B481C6@west.sun.com>
bwarsaw@python.org wrote:
>
> >>>>> "DM" == Dan Mick writes:
>
> >> "RJ" == Ron Jarrell writes:
> >> RJ> Unless the machine crashed, which is why you're fscking
> >> the RJ> file system :-). True, true.
>
> DM> Setting dates in the future seems like a really bad idea to
> DM> me...
>
> Can you elaborate? Are you aware of specific problems?
The heat that will be generated in my brain when I try to use standard date-based
techniques to deal with such files....
No, I don't know of any current program that will or won't break. But it's
certainly what I would call "violating a fundamental precept", and I don't
see why it's necessary; if we need some delta to a future time, the lock file can
always have contents.
It just strikes me as "too clever for its own good, to not very much advantage".
From bwarsaw@python.org Tue May 2 23:23:28 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Tue, 2 May 2000 18:23:28 -0400 (EDT)
Subject: [Mailman-Developers] New LockFile.py
References: <200005020236.TAA11021@utopia.west.sun.com>
<14606.61509.407756.744314@anthem.cnri.reston.va.us>
<390F5364.71B481C6@west.sun.com>
Message-ID: <14607.21856.204400.849516@anthem.cnri.reston.va.us>
>>>>> "DM" == Dan Mick writes:
DM> The heat that will be generated in my brain when I try to use
DM> standard date-based techniques to deal with such files....
Hmm, they will /hopefully/ be transient enough that you may never see
them. If you do catch them, ls does "something reasonable", and you
can always just rm them without too much ill happening (assuming a
quiescent Mailman system).
DM> No, I don't know of any current program that will or won't
DM> break. But it's certainly what I would call "violating a
DM> fundamental precept", and I don't see why it's necessary; if
DM> we need some delta to a future time, the lock file can always
DM> have contents.
The problem is that any algorithm I've been able to come up with that
re-writes the file contents, say when you refresh the lock, is rife
with race conditions. Given that Postfix and Big Brother use similar
techiques, I'm inclined to keep it for Mailman too. But I definitely
appreciate the feedback, and will keep your concerns in mind.
-Barry
From jhebert@compu-aid.com Wed May 3 00:31:36 2000
From: jhebert@compu-aid.com (Jim Hebert)
Date: Tue, 2 May 2000 19:31:36 -0400 (EDT)
Subject: [Mailman-Developers] New LockFile.py
In-Reply-To: <14607.21856.204400.849516@anthem.cnri.reston.va.us>
Message-ID:
Though I'm personally just as happy with future-dates, Barry, if you
really want one more lick at the problem, here's mine: IF:
1) Future dates are a problem
and
2) Manipulating lockfile contents is a problem
How about this:
For a given "now + delta_to_future" that we want to set an expiry:
make a file, set ctime = delta_to_future (ie epoch + delta_to_future)
mtime = now
This is "coherent" for everyone's various tools, has a ctime < mtime <=
now for positive values of delta_to_future. In order to figure out if a
given lockfile needs to expire, you get the ctime as seconds-since-epoch
and add that to mtime, compare to now. Locks can be renewed by either
advancing mtime or ctime, I suppose, so different meaning could be
associated with each if desirable.
Thoughts?
jim
--
Jim Hebert http://www.cosource.com/
jim@cosource.com The cooperative market for open source software
"Well actually I was considering opening a market in flying pigs. Mostly
because it would be more practical...." -- Alan Cox
On Tue, 2 May 2000 bwarsaw@python.org wrote:
> with race conditions. Given that Postfix and Big Brother use similar
> techiques, I'm inclined to keep it for Mailman too. But I definitely
> appreciate the feedback, and will keep your concerns in mind.
From claw@cp.net Wed May 3 01:39:05 2000
From: claw@cp.net (J C Lawrence)
Date: Tue, 02 May 2000 17:39:05 -0700
Subject: [Mailman-Developers] New LockFile.py
In-Reply-To: Message from bwarsaw@python.org (Barry Warsaw)
of "Mon, 01 May 2000 13:43:04 EDT." <14605.49704.849479.12542@anthem.cnri.reston.va.us>
References: <14605.49704.849479.12542@anthem.cnri.reston.va.us>
Message-ID:
On Mon, 1 May 2000 13:43:04 -0400 (EDT)
Barry Warsaw wrote:
> The one questionable aspect of the new LockFile.py is that it uses
> the mtime of the file as the lock's lifetime. This works great
> for avoiding race conditions but means that Mailman is setting
> mtime's of the files to some time in the future. Is anybody aware
> of OSes where this will be a problem? Linux and Solaris both seem
> to stay happy.
Aside: Tripwire, Aide, and other filesystem based attack sensors
will tend to have fits over this. Further, depending on how you
reply on them and their magnitude, interaction with time daemons ala
NTP could cause unexpected results.
--
J C Lawrence Internet: claw@kanga.nu
----------(*) Internet: coder@kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
From brian@gweep.bc.ca Wed May 3 02:22:13 2000
From: brian@gweep.bc.ca (Brian Edmonds)
Date: 02 May 2000 18:22:13 -0700
Subject: [Mailman-Developers] change the envelope sender with Sendmail.py?
In-Reply-To: Nigel Metheringham's message of "Tue, 02 May 2000 09:54:37 +0100"
References:
Message-ID: <37zoq8jum2.fsf@lios.gweep.bc.ca>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nigel Metheringham writes:
> The Sendmail.py module has a number of other problems, and I would
> strongly suggest that it not be used at present - the name is a
> reference to the calling interface used rather than necessarily the
> MTA.
That's well and good, but until I can make the time to convert my whole
MTA setup over to Postfix, I'm going to have to use Sendmail.py as the
interface to my outgoing-only Postfix installation. Sendmail (via
SMTPDirect.py) simply does not work at all well with Mailman 2.0beta2.
And so far it does seem to be working just fine. What sort of problems
would you expect me to be seeing?
Brian.
PS: To recap, I've been using Majordomo with bulk_mailer and Sendmail
for my lists. Sendmail is still my MTA but I've installed Postfix in
outgoing only mode for Mailman to use. I'll switch to Postfix for the
whole enchilada eventually, but that will take some time to set up.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard
iD8DBQE5D39DcCEFQUX5+OwRAnleAJ9GwAJSiUr1SkrSmRQZnnU4UStmawCgvPT1
Rtxlx0lyrnDpq/DZrZvOHu8=
=P2FU
-----END PGP SIGNATURE-----
From Nigel.Metheringham@VData.co.uk Wed May 3 09:31:09 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Wed, 03 May 2000 09:31:09 +0100
Subject: [Mailman-Developers] New LockFile.py
In-Reply-To: Message from J C Lawrence
of "Tue, 02 May 2000 17:39:05 PDT."
Message-ID:
claw@cp.net said:
> Aside: Tripwire, Aide, and other filesystem based attack sensors will
> tend to have fits over this.
Lockfiles being checked within filesystem attack tools will give the
administrator an awful lot of rubbish to examine per day - general
tripwire would be happy as long as the permissions were not silly (ie
setuid), and it was informed that the file (all files in that
directory/filesystem area) were transient data,
Nigel.
--
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]
From Nigel.Metheringham@VData.co.uk Wed May 3 09:35:32 2000
From: Nigel.Metheringham@VData.co.uk (Nigel Metheringham)
Date: Wed, 03 May 2000 09:35:32 +0100
Subject: [Mailman-Developers] change the envelope sender with
Sendmail.py?
In-Reply-To: Message from Brian Edmonds
of "02 May 2000 18:22:13 PDT." <37zoq8jum2.fsf@lios.gweep.bc.ca>
Message-ID:
brian@gweep.bc.ca said:
> That's well and good, but until I can make the time to convert my
> whole MTA setup over to Postfix, I'm going to have to use Sendmail.py
> as the interface to my outgoing-only Postfix installation. Sendmail
> (via SMTPDirect.py) simply does not work at all well with Mailman
> 2.0beta2.
Wierd... why on earth not. Can't you have a localhost SMTP listener?
> And so far it does seem to be working just fine. What sort of
> problems would you expect me to be seeing?
Look back in the archives for the thread "New MTA interface in mailman
2.0b" around 10 April.
Nigel.
--
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham Nigel.Metheringham@VData.co.uk ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]
From brian@gweep.bc.ca Thu May 4 15:21:40 2000
From: brian@gweep.bc.ca (Brian Edmonds)
Date: 04 May 2000 07:21:40 -0700
Subject: [Mailman-Developers] change the envelope sender with Sendmail.py?
In-Reply-To: Nigel Metheringham's message of "Wed, 03 May 2000 09:35:32 +0100"
References:
Message-ID: <3766suieff.fsf@lios.gweep.bc.ca>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nigel Metheringham writes:
>> I'm going to have to use Sendmail.py as the interface to my
>> outgoing-only Postfix installation.
> Wierd... why on earth not. Can't you have a localhost SMTP listener?
I *do* have a localhost SMTP listener, and that's Sendmail, because I've
been using Sendmail for years, and have a slightly complicated mail
setup that will take a bit of time to convert to Postfix.
> Look back in the archives for the thread "New MTA interface in mailman
> 2.0b" around 10 April.
Thanks, will do.
Brian.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard
iD8DBQE5EYdxcCEFQUX5+OwRAnjVAJ0XXcwxnr2+aSAX3GZd7nGP3veBkwCfayMf
/h48XMbxQ1hwTMdUoDS29/0=
=YDAN
-----END PGP SIGNATURE-----
From chuq@apple.com Thu May 4 20:36:50 2000
From: chuq@apple.com (Chuq Von Rospach)
Date: Thu, 4 May 2000 12:36:50 -0700
Subject: [Mailman-Developers] www.list.org is down?
Message-ID:
I'm unable to connect to www.list.org. Is it down?
--
Chuq Von Rospach, Apple Mail List Gnome
(mailto:chuq@apple.com) + (mailto:chuqui@plaidworks.com)
From John@list.org Thu May 4 20:36:27 2000
From: John@list.org (John Viega)
Date: Thu, 4 May 2000 12:36:27 -0700
Subject: [Mailman-Developers] www.list.org is down?
In-Reply-To: ; from Chuq Von Rospach on Thu, May 04, 2000 at 12:36:50PM -0700
References:
Message-ID: <20000504123627.B8384@viega.org>
Yes. We found out last night that we've recently been hacked. We've
had to take down all services until we are fairly confident that we
know how the intruder got in, and that there are no more trojans lying
around.
John
On Thu, May 04, 2000 at 12:36:50PM -0700, Chuq Von Rospach wrote:
>
> I'm unable to connect to www.list.org. Is it down?
>
> --
> Chuq Von Rospach, Apple Mail List Gnome
> (mailto:chuq@apple.com) + (mailto:chuqui@plaidworks.com)
>
>
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://www.python.org/mailman/listinfo/mailman-developers
From bigdog@dogpound.vnet.net Thu May 4 20:39:47 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Thu, 4 May 2000 15:39:47 -0400 (EDT)
Subject: [Mailman-Developers] www.list.org is down?
In-Reply-To:
Message-ID:
On Thu, 4 May 2000, Chuq Von Rospach wrote:
> I'm unable to connect to www.list.org. Is it down?
--- list.org ping statistics ---
12 packets transmitted, 11 packets received, 8% packet loss
round-trip min/avg/max = 426.7/2019.0/5501.5 ms
Looks like router problems maybe? Probably from this recent virus.
--
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/
Another flight attendant's comment on a less than perfect landing: "We
ask you to please remain seated as Captain Kangaroo bounces us to the
terminal."
From gstein@lyra.org Thu May 4 20:43:36 2000
From: gstein@lyra.org (Greg Stein)
Date: Thu, 4 May 2000 12:43:36 -0700 (PDT)
Subject: [Mailman-Developers] www.list.org is down?
In-Reply-To: <20000504123627.B8384@viega.org>
Message-ID:
Actually, the web server should have been up and running. Dunno why it
wasn't. I've restarted it.
FTP is also alive and well, so that people can get Mailman distributions.
We believe we know how the hacker got it, and that has been rectified.
Sorry for any inconvience,
-g
On Thu, 4 May 2000, John Viega wrote:
> Yes. We found out last night that we've recently been hacked. We've
> had to take down all services until we are fairly confident that we
> know how the intruder got in, and that there are no more trojans lying
> around.
>
> John
>
> On Thu, May 04, 2000 at 12:36:50PM -0700, Chuq Von Rospach wrote:
> >
> > I'm unable to connect to www.list.org. Is it down?
> >
> > --
> > Chuq Von Rospach, Apple Mail List Gnome
> > (mailto:chuq@apple.com) + (mailto:chuqui@plaidworks.com)
> >
> >
> > _______________________________________________
> > Mailman-Developers mailing list
> > Mailman-Developers@python.org
> > http://www.python.org/mailman/listinfo/mailman-developers
>
--
Greg Stein, http://www.lyra.org/
From bwarsaw@python.org Thu May 4 23:41:21 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Thu, 4 May 2000 18:41:21 -0400 (EDT)
Subject: [Mailman-Developers] Some refinements coming
Message-ID: <14609.64657.402186.201414@anthem.cnri.reston.va.us>
Some time over the next few days I'm going to check in a bunch of
related refinements which should make message delivery much more
robust than it is in 2.0beta2. In brief, this expands on the
mechanism that SMTPDirect.py used to queue up files for which there
were delivery failures to some or all recipients.
For example, here's a scenario that could cause messages under beta2
to get dropped, but which will be handled more gracefully in beta3.
Say there's some long running process that is claiming a list lock,
e.g. bin/withlist. A message arrives destined for the same list, but
the lock lifetime is fairly long and scripts/post can't acquire the
list lock. Maybe you're running Postfix and you hit
command_time_limit, SIGKILLing post (ouch!). That incoming message is
lost forever, and That's Bad (tm).
What you can do now is set the list lock acquisition timeout to
something shorter than command_time_limit. This would cause
scripts/post to get a TimeoutError on list acquisition, which it can
catch and use to the queue the message. cron/qrunner can then attempt
redelivery the next time it runs.
The new scheme will also mean that delivery failures generated by
Sendmail.py will be queued just like for SMTPDirect.py. Also, if
there any uncaught exceptions in a handler module, the message will be
queued instead of being lost (with a traceback showing up in
logs/errors so you can fix it and try attempt redelivery).
One of the cool things is that a message knows how far in the pipeline
it got, so when qrunner attempts redelivery, it'll pick up where it
left off before, skipping modules that succeeded the first time. Note
though that if you change the pipeline after the message has been
queued, the message will not flow through the new pipeline.
These changes touch many pieces of Mailman and I wish I didn't have to
do this so deeply into the beta cycle, but I think it's really really
important to make sure that messages never get lost. Currently, the
API to delivery modules has changed (which also sucks for a beta
release), but I think I'm going to fix that before beta3 goes out.
This stuff is also only minimally tested, so don't go updating your
production systems yet. I'm not sure I figured out all the nuances or
entry points, but my simple tests work. I want to check it all in so
there's a cvs record of the changes, many of which have been sitting
in my devel directory for days. Also, it'll be nice to have more eyes
look at this stuff.
Stay tuned.
-Barry
From Dan Mick Fri May 5 03:20:37 2000
From: Dan Mick (Dan Mick)
Date: Thu, 4 May 2000 19:20:37 -0700 (PDT)
Subject: [Mailman-Developers] 1.1 bug: mailman home path scattered throughout config.db
Message-ID: <200005050220.TAA13912@utopia.west.sun.com>
Argh.
I just spent an hour trying to figure out why some lists that I'd
moved from a machine with /home/mailman to a machine with
/export/home/mailman would *not* archive.
It's because there were (at least) three variables in config.db
for each list that contain the base path, apparently persistently,
so changing PREFIX in Defaults.py isn't enough:
public_archive_file_dir
private_archive_file_dir
archive_directory
If I don't have something else misconfigured which causes these
to show up in config.db, I call this a bug.
From ckolar@admin.aurora.edu Fri May 5 14:56:01 2000
From: ckolar@admin.aurora.edu (Christopher Kolar)
Date: Fri, 05 May 2000 08:56:01 -0500
Subject: [Mailman-Developers] wrong list info in header (b1)
Message-ID: <4.3.1.2.20000505085013.00d1fd10@admin.aurora.edu>
Hello everyone. I am running 2.0 b1 on a server that has been through all
of the upgrades since 1b6. I was looking at my mail queue this morning and
I noticed something odd about some of the notes sent out with the monthly
reminder. I have actually noticed this in other months previous, but never
got around to reporting it.
It appears that the header info on the monthly reminder reflects that the
traffic is originating from a single list on the server that the person is
not subscribed to. Actually, the list chi-ptech is a small defunct list,
but even my large mail lists have this information in their monthly
header. Here is a sample that I snagged from my queue
>$snorthfield.aocn.aurora.edu
>$_IDENT:mailman@northfield.aocn.aurora.edu [192.203.224.101]
>S
>RPFD:
>H?P?Return-Path:
>HReceived: from northfield.aocn.aurora.edu
>(IDENT:mailman@northfield.aocn.aurora.
>edu [192.203.224.101])
> by northfield.aocn.aurora.edu (8.9.3/8.9.3) with ESMTP id FAA06641
> for ; Mon, 1 May 2000 05:02:39 -0500
>H?D?Date: Mon, 1 May 2000 05:02:39 -0500
>H?M?Message-Id: <200005011002.FAA06641@northfield.aocn.aurora.edu>
>HSubject: aocn.aurora.edu mailing list memberships reminder
>HFrom: mailman-owner@aocn.aurora.edu
>HTo: ceo@blackberrycomputers.com
>HX-No-Archive: yes
>HSender: chi-ptech-admin@aocn.aurora.edu
>HErrors-To: chi-ptech-admin@aocn.aurora.edu
>HX-BeenThere: chi-ptech@aocn.aurora.edu
>HX-Mailman-Version: 2.0beta1
>HPrecedence: bulk
>HList-Id: List for discussion of technology in Chicago-area parochial
>schools. hi-ptech.aocn.aurora.edu>
>.
This person is not a member of chi-ptech, but is a member of a list called
gacc-tech. The body of the message reflects the actual list membership,
but I am confused as to why the header and errors-to info is set to the
other list. As I said, this is true for all users for all of my lists. Is
the point that the monthly reminder all originates from a legitimate admin
address that is picked in some arbitrary way?
Thanks in advance, and sorry if this has been covered before.
--chris
From bwarsaw@python.org Fri May 5 15:45:33 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 5 May 2000 10:45:33 -0400 (EDT)
Subject: [Mailman-Developers] 1.1 bug: mailman home path scattered throughout config.db
References: <200005050220.TAA13912@utopia.west.sun.com>
Message-ID: <14610.56973.616741.618672@anthem.cnri.reston.va.us>
>>>>> "DM" == Dan Mick writes:
DM> Argh.
DM> I just spent an hour trying to figure out why some lists that
DM> I'd moved from a machine with /home/mailman to a machine with
DM> /export/home/mailman would *not* archive.
DM> It's because there were (at least) three variables in
DM> config.db for each list that contain the base path, apparently
DM> persistently, so changing PREFIX in Defaults.py isn't enough:
| public_archive_file_dir
| private_archive_file_dir
| archive_directory
DM> If I don't have something else misconfigured which causes
DM> these to show up in config.db, I call this a bug.
Yes, this is bogus, and unfortunately it won't go away in 2.0.
Fortunately, bin/move_list (in the 2.0 tree) should fix your problem
efficiently.
-Barry
From bigdog@dogpound.vnet.net Fri May 5 15:55:07 2000
From: bigdog@dogpound.vnet.net (Matt Davis)
Date: Fri, 5 May 2000 10:55:07 -0400 (EDT)
Subject: [Mailman-Developers] wrong list info in header (b1)
In-Reply-To: <4.3.1.2.20000505085013.00d1fd10@admin.aurora.edu>
Message-ID:
On Fri, 5 May 2000, Christopher Kolar wrote:
> It appears that the header info on the monthly reminder reflects that the
> traffic is originating from a single list on the server that the person is
> not subscribed to. Actually, the list chi-ptech is a small defunct list,
> but even my large mail lists have this information in their monthly
> header. Here is a sample that I snagged from my queue
This is from one a user of mine got...
Return-Path:
Received: from dogpound.vnet.net (mailman@localhost [127.0.0.1])
by dogpound.vnet.net (8.9.3/8.9.3) with ESMTP id FAA26196
for ; Mon, 1 May 2000 05:00:31 -0400
Date: Mon, 1 May 2000 05:00:31 -0400
Message-Id: <200005010900.FAA26196@dogpound.vnet.net>
Subject: dogpound.vnet.net mailing list memberships reminder
From: mailman-owner@dogpound.vnet.net
To: wayned@dogpound.vnet.net
X-No-Archive: yes
Sender: davis-admin@dogpound.vnet.net
Errors-To: davis-admin@dogpound.vnet.net
X-BeenThere: davis@dogpound.vnet.net
X-Mailman-Version: 2.0beta3
Precedence: bulk
List-Id: Davis Family Mailing List
Status:
And that list is infact the one a user is subscribed to.. Maybe this was
fixed from beta1 -> beta3?
--
Matt Davis - ICQ# 934680
http://dogpound.vnet.net/
SENILE.COM found... Out Of Memory.
From adrian.joseph@guardian.co.uk Fri May 5 17:57:24 2000
From: adrian.joseph@guardian.co.uk (Adrian Joseph)
Date: Fri, 05 May 2000 17:57:24 +0100
Subject: [Mailman-Developers] A request - increased clarity in -request responses
Message-ID: <3912FD74.2A7BA54C@guardian.co.uk>
Hi, I'm not a subscriber to this list, but I'm the admin for a number of
mailing lists using Mailman v1.1. One thing which has proved to be a
problem is the relative lack of clarity in the replies to mailcmd
subscribe & unsubscribe attempts. Since it has become common for
companies to tack on lengthy legal disclaimers, the resulting output
from the parser, ending in " Too many errors encountered; the rest of
the message is ignored:", is more than enough to confuse those who are
not computer savvy=B7 I know the relevant information is present in the
mail, but I've had literally hundreds of e-mail from confused would-be
subscribers to demonstrate that its presentation needs some improvement.
Griping aside I think its a pretty cool app, thanks folks
Adrian
From thomas@xs4all.net Mon May 8 11:58:20 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 8 May 2000 12:58:20 +0200
Subject: [Mailman-Developers] A request - increased clarity in -request responses
In-Reply-To: <3912FD74.2A7BA54C@guardian.co.uk>; from adrian.joseph@guardian.co.uk on Fri, May 05, 2000 at 05:57:24PM +0100
References: <3912FD74.2A7BA54C@guardian.co.uk>
Message-ID: <20000508125820.F3309@xs4all.nl>
On Fri, May 05, 2000 at 05:57:24PM +0100, Adrian Joseph wrote:
> Hi, I'm not a subscriber to this list, but I'm the admin for a number of
> mailing lists using Mailman v1.1. One thing which has proved to be a
> problem is the relative lack of clarity in the replies to mailcmd
> subscribe & unsubscribe attempts. Since it has become common for
> companies to tack on lengthy legal disclaimers, the resulting output
> from the parser, ending in " Too many errors encountered; the rest of
> the message is ignored:", is more than enough to confuse those who are
> not computer savvy· I know the relevant information is present in the
> mail, but I've had literally hundreds of e-mail from confused would-be
> subscribers to demonstrate that its presentation needs some improvement.
> Griping aside I think its a pretty cool app, thanks folks
Well, Barry must have been using Guido's time machine again, because that
problem is already fixed. And more than that, too, because Barry flew back a
lot farther and fixed Majordomo too ;-)
You can force mailman to stop parsing mail commands two ways: by using 'end'
as a command, or by starting a line with '--'. By strange coincidence, '--'
(actually '-- ', two dashes with a trailing space) is the commonly accepted
and well documented way to start a signature -- precisely so that mail
robots and filters and what not can distinguish the message text from the
signature.
Want to help the not very computer savvy ? Force their mail administrators
to tack the legal statements on the end as a signature, starting it with the
recognized prefix, '-- '. Good mail (and news) programs do this
automatically, bless their programmers' little hearts, but unfortunately
some refuse to follow almost-standards. Most unfortunate for Mailman, which
has to take a lot of different mail programs (client and server) into
account :P
--
Thomas Wouters
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
From thomas@xs4all.net Mon May 8 12:48:36 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Mon, 8 May 2000 13:48:36 +0200
Subject: [Mailman-Developers] wrong list info in header (b1)
In-Reply-To: <4.3.1.2.20000505085013.00d1fd10@admin.aurora.edu>; from ckolar@admin.aurora.edu on Fri, May 05, 2000 at 08:56:01AM -0500
References: <4.3.1.2.20000505085013.00d1fd10@admin.aurora.edu>
Message-ID: <20000508134836.G3309@xs4all.nl>
On Fri, May 05, 2000 at 08:56:01AM -0500, Christopher Kolar wrote:
> It appears that the header info on the monthly reminder reflects that the
> traffic is originating from a single list on the server that the person is
> not subscribed to. Actually, the list chi-ptech is a small defunct list,
> but even my large mail lists have this information in their monthly
> header. Here is a sample that I snagged from my queue
[ snip ]
> Is the point that the monthly reminder all originates from a legitimate
> admin address that is picked in some arbitrary way?
Yes, that's exactly the point. The script responsible for sending the
password reminders, cron/mailpasswds, specifically uses the first public
list it finds to send all password reminders. I'm not entirely sure why this
is done, except for some marginal performance issue. This does present a
small bug though: when there is no public list, password reminders are
simply not sent ;-P
mailpasswds should probably be rewritten to either use a list the user is
on, or use a fake list... I'm not really sure which is best, considering
people with mailfilters based on Sender and such.
--
Thomas Wouters
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
From Harald.Meland@usit.uio.no Mon May 8 17:31:33 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 08 May 2000 18:31:33 +0200
Subject: [Mailman-Developers] change the envelope sender with Sendmail.py?
In-Reply-To: Brian Edmonds's message of "30 Apr 2000 14:22:44 -0700"
References: <37em7n472z.fsf@lios.gweep.bc.ca>
Message-ID:
[Brian Edmonds]
> The change is on line 91 of Handlers/Sendmail.py[1], where msg.GetSender
> needs to become mlist.GetAdminEmail.
As I mentioned some weeks ago on this same issue, I think it would be
better to override the GetSender() method appropriately for the
various subclasses of Message.
If you hardcode in GetAdminEmail as envelope sender, you can get
"interesting" results when combined with MTA sender verification and
e.g. newly created lists. It will also cause e.g. password reminder
bounces to go to some unsuspecting (public) list's admin and not to
mailman-owner.
--
Harald
From mats@laplaza.org Mon May 8 18:03:26 2000
From: mats@laplaza.org (Mats Wichmann)
Date: Mon, 08 May 2000 11:03:26 -0600
Subject: [Mailman-Developers] New LockFile.py
In-Reply-To:
References:
<14605.49704.849479.12542@anthem.cnri.reston.va.us>
Message-ID: <3.0.6.32.20000508110326.00eef9f0@laplaza.org>
At 05:39 PM 05/02/2000 -0700, J C Lawrence wrote:
>On Mon, 1 May 2000 13:43:04 -0400 (EDT)
>Barry Warsaw wrote:
>
>> The one questionable aspect of the new LockFile.py is that it uses
>> the mtime of the file as the lock's lifetime. This works great
>> for avoiding race conditions but means that Mailman is setting
>> mtime's of the files to some time in the future. Is anybody aware
>> of OSes where this will be a problem? Linux and Solaris both seem
>> to stay happy.
>
>Aside: Tripwire, Aide, and other filesystem based attack sensors
>will tend to have fits over this.
I have to admit to a vague discomfort over the technique, but
I don't buy any of the arguments presented here against it.
So what if fsck has a hairball (which I don't expect)? It's
checking a transient file which is no longer in use, since
the file system has been dismounted and thus the process
using it must no longer be using it (probably the filesystem
is dismounted due to a crash and we've rebooted).
Tripwire? Shouldn't be checking transient lockfiles anyway.
Mats
From ddickey@wamnet.com Tue May 9 16:43:29 2000
From: ddickey@wamnet.com (Dan A. Dickey)
Date: Tue, 09 May 2000 10:43:29 -0500
Subject: [Mailman-Developers] Extraordinary locking mechanisms...
References:
<14605.49704.849479.12542@anthem.cnri.reston.va.us> <3.0.6.32.20000508110326.00eef9f0@laplaza.org>
Message-ID: <39183221.B77C1C1D@wamnet.com>
Well, I figure its finally time for me to ask
a stupid question.
Why do people use filesystems for locking?
Why not use IPC semaphores instead?
It seems that people are going through extraordinary
trouble and grief to get the filesystem locking correct.
Like I said - it may be a stupid question, and I'm
just not getting something. What is that something?
One of the more reasonable and understandable benefits
of using filesystem locking is when the locks are placed
in a shared filesystem - a filesystem that is used by
multiple machines running Mailman. Is this a common
occurrence?
-Dan
--
Dan A. Dickey
ddickey@wamnet.com
From lindsey@ncsa.uiuc.edu Tue May 9 16:46:51 2000
From: lindsey@ncsa.uiuc.edu (Christopher Lindsey)
Date: Tue, 9 May 2000 10:46:51 -0500 (CDT)
Subject: [Mailman-Developers] Extraordinary locking mechanisms...
In-Reply-To: <39183221.B77C1C1D@wamnet.com> from "Dan A. Dickey" at May 09, 2000 10:43:29 AM
Message-ID: <200005091546.KAA10026@glorfindel.ncsa.uiuc.edu>
> One of the more reasonable and understandable benefits
> of using filesystem locking is when the locks are placed
> in a shared filesystem - a filesystem that is used by
> multiple machines running Mailman. Is this a common
> occurrence?
Hi Dan,
Many people split the Web and email portions of Mailman up,
running each on its own server. That's what I do at mallorn.com,
and here at NCSA we're taking it a step further with four
mail servers and three Web servers (round-robined) all providing
the same functionality. Of course, the glue that holds it all
together is the filesystem (we tried doing Mailman in AFS, but
it was a pain getting our patches to work on new versions... We
ended up having to settle for (ick) NFS).
Chris
From ddickey@wamnet.com Tue May 9 16:55:45 2000
From: ddickey@wamnet.com (Dan A. Dickey)
Date: Tue, 09 May 2000 10:55:45 -0500
Subject: [Mailman-Developers] Bugs in Utils.py and pythonlib/smtplib.py (Mailman 1.1)
Message-ID: <39183501.466FF434@wamnet.com>
This is a multi-part message in MIME format.
--------------F3D9F94D47DB27159776C770
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Here are a couple of patches to fix file descriptor leaks
in Utils.py, and pythonlib/smtplib.py. I looked at the new
beta of Mailman, and it didn't seem as if these bugs had been
fixed - so probably nobody has hit these but me.
The bugs are seen when sending too much to sendmail and sendmail
decides to close up shop for about 15 seconds. Then, fds are leaked,
and eventually run_queue crashes and leaves a lock file around
(locking problem again).
I'd suggest someone work these patches into the new Mailman code;
sorry I can't do it myself.
-Dan
--
Dan A. Dickey
ddickey@wamnet.com
--------------F3D9F94D47DB27159776C770
Content-Type: text/plain; charset=us-ascii;
name="Utils-fdleak.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Utils-fdleak.patch"
*** Utils.py.orig Thu Dec 9 08:48:41 1999
--- Utils.py Mon Apr 24 10:31:46 2000
***************
*** 25,30 ****
--- 25,31 ----
import sys
import os
+ import time
import string
import re
from UserDict import UserDict
***************
*** 333,338 ****
--- 334,341 ----
if log_hint:
l.write(' %s\n' % log_hint)
l.flush()
+ l.close()
+ time.sleep(1.0)
--------------F3D9F94D47DB27159776C770
Content-Type: text/plain; charset=us-ascii;
name="smptlib.fdleak.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="smptlib.fdleak.patch"
*** pythonlib/smtplib.py.orig Thu Dec 9 08:48:44 1999
--- pythonlib/smtplib.py Mon Apr 24 10:09:28 2000
***************
*** 213,219 ****
if not port: port = SMTP_PORT
self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
if self.debuglevel > 0: print 'connect:', (host, port)
! self.sock.connect(host, port)
(code,msg)=self.getreply()
if self.debuglevel >0 : print "connect:", msg
return (code,msg)
--- 213,224 ----
if not port: port = SMTP_PORT
self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
if self.debuglevel > 0: print 'connect:', (host, port)
! try:
! self.sock.connect(host, port)
! except:
! if self.debuglevel > 0: print 'connect failed, raising sock.error'
! self.close()
! raise socket.error, "connect failed"
(code,msg)=self.getreply()
if self.debuglevel >0 : print "connect:", msg
return (code,msg)
--------------F3D9F94D47DB27159776C770--
From Harald.Meland@usit.uio.no Tue May 9 18:35:47 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 09 May 2000 19:35:47 +0200
Subject: [Mailman-Developers] Bugs in Utils.py and pythonlib/smtplib.py (Mailman 1.1)
In-Reply-To: "Dan A. Dickey"'s message of "Tue, 09 May 2000 10:55:45 -0500"
References: <39183501.466FF434@wamnet.com>
Message-ID:
--=-=-=
[Dan A. Dickey]
> Here are a couple of patches
Thanks!
> to fix file descriptor leaks in Utils.py,
The message delivery stuff has changed a lot since 1.1, so there's no
longer any TrySMTPDelivery() function in Utils.py.
> and pythonlib/smtplib.py.
The modules under Mailman/pythonlib in the distribution are merely
copies of the current version of various modules that accompany python
itself. Thus, if there are bugs in these modules, they should be
reported to the python maintainers.
In this case, though, I don't think there is a bug per se in the
smtplib library -- rather, it's Mailman that doesn't take enough care
in closing up file descriptors.
Below is a quick patch against current CVS Mailman for those cron
scripts I have seen run out of available file descriptors (when
there's a lot of lists to iterate over). I don't actually run CVS
Mailman at the moment, so the patch has not been tested.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=mailman-closelogs-cron.diff
? cron/postauthenticate
? cron/preauthenticate
Index: cron/checkdbs
===================================================================
RCS file: /export/public/cvsroot/mailman/cron/checkdbs,v
retrieving revision 1.21
diff -u -r1.21 checkdbs
--- checkdbs 2000/05/08 22:24:42 1.21
+++ checkdbs 2000/05/09 17:29:54
@@ -58,6 +58,7 @@
finally:
mlist.Save()
mlist.Unlock()
+ mlist.CloseLogs()
Index: cron/gate_news
===================================================================
RCS file: /export/public/cvsroot/mailman/cron/gate_news,v
retrieving revision 1.28
diff -u -r1.28 gate_news
--- gate_news 2000/04/07 04:46:30 1.28
+++ gate_news 2000/05/09 17:29:55
@@ -208,6 +208,7 @@
finally:
mlist.Save()
mlist.Unlock()
+ mlist.CloseLogs()
os._exit(status)
# we're done forking off all the gating children, now just wait for them
# all to exit, and then we're done
Index: cron/senddigests
===================================================================
RCS file: /export/public/cvsroot/mailman/cron/senddigests,v
retrieving revision 1.14
diff -u -r1.14 senddigests
--- senddigests 2000/03/21 06:26:25 1.14
+++ senddigests 2000/05/09 17:29:55
@@ -58,6 +58,7 @@
finally:
mlist.Save()
mlist.Unlock()
+ mlist.CloseLogs()
--=-=-=
--
Harald
--=-=-=--
From Harald.Meland@usit.uio.no Tue May 9 18:51:33 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 09 May 2000 19:51:33 +0200
Subject: [Mailman-Developers] change the envelope sender with Sendmail.py?
In-Reply-To: Harald Meland's message of "08 May 2000 18:31:33 +0200"
References: <37em7n472z.fsf@lios.gweep.bc.ca>
Message-ID:
--=-=-=
[Harald Meland]
> [Brian Edmonds]
>
> > The change is on line 91 of Handlers/Sendmail.py[1], where msg.GetSender
> > needs to become mlist.GetAdminEmail.
>
> As I mentioned some weeks ago on this same issue, I think it would be
> better to override the GetSender() method appropriately for the
> various subclasses of Message.
>
> If you hardcode in GetAdminEmail as envelope sender, you can get
> "interesting" results when combined with MTA sender verification and
> e.g. newly created lists. It will also cause e.g. password reminder
> bounces to go to some unsuspecting (public) list's admin and not to
> mailman-owner.
Some might consider that a feature, of course ;)
I finally got round to backporting these changes to CVS mailman:
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=mailman-envelope-sender.diff
Index: Mailman//Message.py
===================================================================
RCS file: /export/public/cvsroot/mailman/Mailman/Message.py,v
retrieving revision 1.29
diff -u -r1.29 Message.py
--- Message.py 2000/05/08 22:23:17 1.29
+++ Message.py 2000/05/09 17:48:04
@@ -183,3 +183,7 @@
self['From'] = sender
self['To'] = recip
self.recips = [recip]
+ self.notification_sender = sender
+
+ def GetSender(self):
+ return self.notification_sender
Index: Mailman//Handlers/SMTPDirect.py
===================================================================
RCS file: /export/public/cvsroot/mailman/Mailman/Handlers/SMTPDirect.py,v
retrieving revision 1.8
diff -u -r1.8 SMTPDirect.py
--- SMTPDirect.py 2000/05/08 17:28:19 1.8
+++ SMTPDirect.py 2000/05/09 17:48:05
@@ -49,7 +49,7 @@
try:
# make sure the connect happens, which won't be done by the
# constructor if SMTPHOST is false
- envsender = mlist.GetAdminEmail()
+ envsender = msg.GetSender()
refused = conn.sendmail(envsender, recips, str(msg))
finally:
t1 = time.time()
Index: Mailman//Handlers/Sendmail.py
===================================================================
RCS file: /export/public/cvsroot/mailman/Mailman/Handlers/Sendmail.py,v
retrieving revision 1.7
diff -u -r1.7 Sendmail.py
--- Sendmail.py 2000/05/08 17:28:19 1.7
+++ Sendmail.py 2000/05/09 17:48:05
@@ -53,7 +53,7 @@
# Nobody to deliver to!
return
# Use -f to set the envelope sender
- cmd = mm_cfg.SENDMAIL_CMD + ' -f ' + mlist.GetAdminEmail() + ' '
+ cmd = mm_cfg.SENDMAIL_CMD + ' -f ' + msg.GetSender() + ' '
# make sure the command line is of a manageable size
recipchunks = []
currentchunk = []
--=-=-=
As usual, I haven't tested the patch with CVS Mailman -- it's just a
backporting of the code we've been running here during the last
months.
--
Harald
--=-=-=--
From Harald.Meland@usit.uio.no Tue May 9 19:07:26 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 09 May 2000 20:07:26 +0200
Subject: [Mailman-Developers] wrong list info in header (b1)
In-Reply-To: Thomas Wouters's message of "Mon, 8 May 2000 13:48:36 +0200"
References: <4.3.1.2.20000505085013.00d1fd10@admin.aurora.edu>
<20000508134836.G3309@xs4all.nl>
Message-ID:
[Thomas Wouters]
> The script responsible for sending the password reminders,
> cron/mailpasswds, specifically uses the first public list it finds
> to send all password reminders. I'm not entirely sure why this is
> done, except for some marginal performance issue.
I think the reasoning went like this: As any reminder message can
contain info about more than one list membership, it's impossible to
use the "correct" list for delivery. Thus, as Mailman can't get this
completely right, it rather chooses the easiest solution available;
use the same list for all deliveries.
Of course, as non-public lists shouldn't be advertised, Mailman
shouldn't "implicitly advertise" a non-public list by using its
message delivery mechanisms (which currently implies putting the
list's name in the message headers) for sending out passwords.
> mailpasswds should probably be rewritten to either use a list the
> user is on, or use a fake list... I'm not really sure which is best,
> considering people with mailfilters based on Sender and such.
I think the last option would be best, because it's the least
complicated thing to implement, and thus less error-prone. Besides,
there also are other reasons for wanting a non-list-specific Mailman
entry point address.
--
Harald
From Harald.Meland@usit.uio.no Tue May 9 19:14:07 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 09 May 2000 20:14:07 +0200
Subject: [Mailman-Developers] using real user names for list members
In-Reply-To: Matthias Klose's message of "Tue, 2 May 2000 10:50:11 +0200 (MET DST)"
References: <14606.38595.645110.766375@gargle.gargle.HOWL>
Message-ID:
[Matthias Klose]
> Is it currently possible/or planned to use names like
>
> Real Name
> email address (Real name)
>
> as the name of a subscriber?
Others have made the very same request, but I don't think anyone has
done any work in this area. Maybe we should think about having
something like this when we spec what the user database should
contain?
--
Harald
From Harald.Meland@usit.uio.no Tue May 9 19:25:07 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 09 May 2000 20:25:07 +0200
Subject: [Mailman-Developers] suggestion for heldmsg placement
In-Reply-To: Ricardo Kustner's message of "Sun, 30 Apr 2000 23:50:37 +0200"
References: <20000430235037.C10063@miss-janet.com>
Message-ID:
[Ricardo Kustner]
> Hi,
>
> I think it could be better to place the heldmsg-* files
> that are created for messages held for approval in
> a directory like ~mailman/listname/lists/mailinglist/pending
> instead of all messages for all lists in ~mailman/data...
> does anybody agree with me? :)
I disagree -- the way it's done now, you can easily have
$(prefix)/data/ (and e.g. archives/) on a big/slow disk, while
$(prefix)/lists/ (and e.g. locks/) can live happily on a
smaller/quicker disk.
Putting stuff in subdirs of the list config dir would require me to
create an awful lot of symlinks in order to do the same.
If you're concerned with the number of files in a single directory, I
guess some scheme for splitting the data/ directory could be
implemented -- but I'm not really sure that's needed.
So, what is you motivation for asking for this change?
--
Harald
From bwarsaw@python.org Tue May 9 19:37:08 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Tue, 9 May 2000 14:37:08 -0400 (EDT)
Subject: [Mailman-Developers] wrong list info in header (b1)
References: <4.3.1.2.20000505085013.00d1fd10@admin.aurora.edu>
<20000508134836.G3309@xs4all.nl>
Message-ID: <14616.23252.960619.351654@anthem.cnri.reston.va.us>
>>>>> "HM" == Harald Meland writes:
HM> I think the last option would be best, because it's the least
HM> complicated thing to implement, and thus less error-prone.
HM> Besides, there also are other reasons for wanting a
HM> non-list-specific Mailman entry point address.
I completely agree.
From Harald.Meland@usit.uio.no Tue May 9 19:50:04 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 09 May 2000 20:50:04 +0200
Subject: [Mailman-Developers] race condition in locking ?
In-Reply-To: bwarsaw@python.org's message of "Tue, 2 May 2000 17:09:07 -0400 (EDT)"
References: <20000202225346.B17313@xs4all.nl>
<20000204205630.A4871@miss-janet.com>
<20000204212243.B4871@miss-janet.com> <20000204234757.A2826@xs4all.nl>
<20000205011507.A405@miss-janet.com> <20000205164318.A15909@xs4all.nl>
<20000205205653.A4105@miss-janet.com>
<20000205232130.D23471@xs4all.nl> <20000207204331.A444@miss-janet.com>
<20000207213143.B444@miss-janet.com> <20000207225907.M19265@xs4all.nl>
<14607.17395.978323.325049@anthem.cnri.reston.va.us>
Message-ID:
[bwarsaw@python.org]
> I've done a bit of testing using Apache and both NS and MSIE. What
> I did was add a big sleep in admin.py, in main(), just before the
> finally at the bottom of the function.
Immediately after the 'print doc.Format()' statement? Then you
shouldn't get any SIGPIPEs, right?
> I added some debug prints so I could see what was going on.
>
> As near as I can tell, if I hit the browser's stop button after
> entering that big sleep, the CGI process gets kill stone cold. It
> never reach the finally clause, doesn't get a SIGPIPE, nothing.
Ouch. Does that imply a SIGKILL, or are there other signals which
could produce such behaviour?
> Since I can't reproduce this, I'm not sure what the right thing to
> do is.
I can't reproduce it either -- although I suspect at least part of the
problem might be ugly TCP/IP stacks and/or browsers (if hitting the
"stop" button doesn't actually close down the TCP connection properly,
I guess there could be problems once the CGI script tries sending data
down the partially closed socket).
> Harald, what webserver are you running?
The problems my users reported was from a Mailman installation using
Apache 1.3.2 on Solaris 2.6. I don't know what web browsers were
being used (and it's been a while since anyone reported a problem like
this).
--
Harald
From Harald.Meland@usit.uio.no Tue May 9 20:12:49 2000
From: Harald.Meland@usit.uio.no (Harald Meland)
Date: 09 May 2000 21:12:49 +0200
Subject: [Mailman-Developers] cookies
In-Reply-To: Ricardo Kustner's message of "Wed, 15 Mar 2000 20:40:48 +0100"
References: <20000315204048.B1040@miss-janet.com>
Message-ID:
[Ricardo Kustner]
> Hi,
>
> this was just suggested to me by somebody from mailman-users:
>
> > Please write a patch which puts the string "Cookie could not be set" on the
> > web page so that I can see that pressing submit will not work :-)
>
> i think thats a good point... it would safe some user questions if
> MM tells exactly why the authorisation failed.
While I agree that such a warning would be nice, I don't think it's
possible to do such things with cookies.
> I'm not sure if this subject has been touched already, but what
> allowing admins to choose between cookies and
> Basic-Authorization... it should be possible to use Basic-auth,
> right?
What is Basic-Authorization? If it doesn't involve a HTTP POST of the
admin login page, I believe it will not work (out of the box, anyway).
--
Harald
From bwarsaw@python.org Tue May 9 21:39:24 2000
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Tue, 9 May 2000 16:39:24 -0400 (EDT)
Subject: [Mailman-Developers] Current round of checkins are finished
Message-ID: <14616.30588.134873.552695@anthem.cnri.reston.va.us>
I've checked in all my current modifications to make losing messages
much less likely. I'm sure there are bugs lurking about, so be
careful if you're running the CVS snapshot. I'm going to spend a few
hours over the next couple of days testing things so watch for more
patches. If you do play with the snapshot and find problems, please
let me know. Figure if I get some time, there will be a beta this
weekend.
-Barry
From ricardo@rixhq.nu Tue May 9 23:48:26 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Wed, 10 May 2000 00:48:26 +0200
Subject: [Mailman-Developers] suggestion for heldmsg placement
In-Reply-To: ; from Harald.Meland@usit.uio.no on Tue, May 09, 2000 at 08:25:07PM +0200
References: <20000430235037.C10063@miss-janet.com>
Message-ID: <20000510004826.A17920@miss-janet.com>
On Tue, May 09, 2000 at 08:25:07PM +0200, Harald Meland wrote:
> > I think it could be better to place the heldmsg-* files
> > that are created for messages held for approval in
> > a directory like ~mailman/listname/lists/mailinglist/pending
> > instead of all messages for all lists in ~mailman/data...
> > does anybody agree with me? :)
> I disagree -- the way it's done now, you can easily have
> $(prefix)/data/ (and e.g. archives/) on a big/slow disk, while
> $(prefix)/lists/ (and e.g. locks/) can live happily on a
> smaller/quicker disk.
> If you're concerned with the number of files in a single directory, I
> guess some scheme for splitting the data/ directory could be
> implemented -- but I'm not really sure that's needed.
> So, what is you motivation for asking for this change?
for me personally it's not a big problem right now since I don't run
that many different lists on one server, but I can imagine that with a site
hosting many mailman lists it could be a lot of files from different lists
in the same directory... most of all it feels more 'structured' to me to
have them separated and keep all data of every list in it's own place...
but it's not really a big issue... i just wanted to point it out and see
what others have to think about it...
Ricardo.
--
From ricardo@rixhq.nu Wed May 10 00:08:22 2000
From: ricardo@rixhq.nu (Ricardo Kustner)
Date: Wed, 10 May 2000 01:08:22 +0200
Subject: [Mailman-Developers] cookies
In-Reply-To: ; from Harald.Meland@usit.uio.no on Tue, May 09, 2000 at 09:12:49PM +0200
References: <20000315204048.B1040@miss-janet.com>
Message-ID: <20000510010822.B17920@miss-janet.com>
Hi,
On Tue, May 09, 2000 at 09:12:49PM +0200, Harald Meland wrote:
> > > Please write a patch which puts the string "Cookie could not be set" on the
> > > web page so that I can see that pressing submit will not work :-)
> > i think thats a good point... it would safe some user questions if
> > MM tells exactly why the authorisation failed.
> While I agree that such a warning would be nice, I don't think it's
> possible to do such things with cookies.
it's possible to set a test cookie to see if cookies are enabled...(and
writing a "your browser doesn't allow / can't set cookies" warning if it fails)...
if the test is OK but the authorisation failed, an authorization error could
be printed. or am i missing the point? :)
> > I'm not sure if this subject has been touched already, but what
> > allowing admins to choose between cookies and
> > Basic-Authorization... it should be possible to use Basic-auth,
> > right?
> What is Basic-Authorization? If it doesn't involve a HTTP POST of the
> admin login page, I believe it will not work (out of the box, anyway).
Basic-auth is a cgi process sending an 401 auth required http header
and thus asking the browser to prompt for a username and password...
I'm not 100% sure if it's possible with a cgi script though (I know it's
possible in PHP but I've never tried it in cgi...)
Ricardo.
--
From thomas@xs4all.net Wed May 10 09:53:13 2000
From: thomas@xs4all.net (Thomas Wouters)
Date: Wed, 10 May 2000 10:53:13 +0200
Subject: [Mailman-Developers] cookies
In-Reply-To: <20000510010822.B17920@miss-janet.com>; from ricardo@rixhq.nu on Wed, May 10, 2000 at 01:08:22AM +0200
References: <20000315204048.B1040@miss-janet.com> <20000510010822.B17920@miss-janet.com>
Message-ID: <20000510105313.C13281@xs4all.nl>
On Wed, May 10, 2000 at 01:08:22AM +0200, Ricardo Kustner wrote:
> > What is Basic-Authorization? If it doesn't involve a HTTP POST of the
> > admin login page, I believe it will not work (out of the box, anyway).
> Basic-auth is a cgi process sending an 401 auth required http header
> and thus asking the browser to prompt for a username and password...
> I'm not 100% sure if it's possible with a cgi script though (I know it's
> possible in PHP but I've never tried it in cgi...)
Basic auth is possible in CGI; you just have to make sure your webserver
allows you to send HTTP response codes. If I recall correctly, you can do
this in Apache by naming your script 'nph-