On Mon, Apr 15, 2002 at 07:55:01AM -0400, Tom Neff wrote:
"Billie R. McNamara" <billie@tnhillbillie.net> wrote:
We are using version 2.0.8 for a moderated list. But, we aren't able to edit messages before approving them (for example, to delete just one inappropriate word).
How can we do this?
There is a FAQ entry that wants you to hand edit various spool files, but you can patch 2.0.8 to allow message editing.
I think the patch will be necessary for mailman 2.1, it unfortunately stores the message on disk in a database format, making hand editing on the mm server not that easy.
Marc
Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
"MM" == Marc MERLIN <marc_news@vasoftware.com> writes:
>> There is a FAQ entry that wants you to hand edit various spool
>> files, but you can patch 2.0.8 to allow message editing.
MM> I think the patch will be necessary for mailman 2.1, it
MM> unfortunately stores the message on disk in a database format,
MM> making hand editing on the mm server not that easy.I've updated the FAQ entry with some useful information for MM2.1.
-Barry
On Thu, Apr 18, 2002 at 06:02:30PM -0400, Barry A. Warsaw wrote:
I've updated the FAQ entry with some useful information for MM2.1.
Cool, thanks.
BTW, I *very* seldom edit messages that are held for moderation. I think twice it was because I forgot to change my posting address from my private one (the one I shouldn't have posted with in the first place :-D) (yes, I know my scheme is flawed)
Once I think I fixed the spelling of someone's name with the poster's approval.
It is however good to see that you allowed to disable the mm2.1 behavior by setting HOLD_MESSAGES_AS_PICKLES to 0. Ideally it'd be in Defaults.py so that it doesn't get blown away on upgrade, but that's already a good thing. I think one use for having held message in plaintext (mostly in a corporate environment) would be to edit headers automatically and/or add a disclaimer or some other info in *some* posts (i.e. a P* script would look at that queue twice a minute and process messages if applicable) Out of curiosity, is it really faster to have the whole mesage in a pickle instead of plaintext?
Another titbit (sp?) of info: On sf.net, I stat files held for moderation and delete everything that's been there for more than a month. You'd be surprised how many spams held for moderation and never moderated we had before that :-)
I'll probably also contribute a small script that watches the number of messages in the mailman queue, and sends a warning if there are more than X (meaning that you have some serious backlog, or some other problem)
Marc
Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
"MM" == Marc MERLIN <marc_news@vasoftware.com> writes:
MM> Ideally it'd be in Defaults.py so that it doesn't get blown
MM> away on upgrade, but that's already a good thing.See my recent checkin. :)
MM> Out of curiosity, is it really faster to have the whole mesage
MM> in a pickle instead of plaintext?I actually don't remember if I timed it or not, but I suspect it has to be faster to do a binary unpickle than to re-parse and re-generate for each queue move. It probably matters little for held messages.
MM> Another titbit (sp?) of info: On sf.net, I stat files held for
MM> moderation and delete everything that's been there for more
MM> than a month. You'd be surprised how many spams held for
MM> moderation and never moderated we had before that :-)Now that would be a cool script to add, although with SpamAssassin, we've been able to /vastly/ reduce the amount of spam coming through python.org. The right tool for the job, etc...
MM> I'll probably also contribute a small script that watches the
MM> number of messages in the mailman queue, and sends a warning
MM> if there are more than X (meaning that you have some serious
MM> backlog, or some other problem)Which reminds me, how's your performance been with Exim4? We're seeing a lot of weird stuff happen that wasn't happening with Exim3, specifically, we seem to exhaust our open file limit about every 3rd or 4th day. It's so bad that Mailman will throw a traceback indicating it couldn't import a module (which is presumably because Python couldn't open the module file to read from). I've seen this wedge Mailman and I've also seen Mailman recover, and I haven't been able to totally correlate this with peak traffic. It's disturbing and we'll have to do something about it, although hopefully not as drastic as reverting to Exim3. I'm just wondering if any other Exim4 users are seeing similar problems.
-Barry
At 18:04 -0400 4/19/2002, Barry A. Warsaw wrote:
... specifically, we seem to exhaust our open file limit about every 3rd or 4th day. ... It's disturbing and we'll have to do something about it, although hopefully not as drastic as reverting to Exim3. I'm just wondering if any other Exim4 users are seeing similar problems.
We haven't moved to either Mailman 2.1 or Exim 4 (on the Mailman machine) yet.
But...we are seeing a Python-based web dynamic page server (not Zope...in-house) leaving open files behind with a fairly new Python.
We've temporized by having a monitor which does a suitable lsof and counts the relevant open files...killing and restarting that server when the count reaches 1000.
I'll pass along to the (really sharp) guy who is working on that problem that you're seeing something at least vaguely similar. We've been operating on the theory that the problem is in our code, but...perhaps not?
--John
-- John Baxter jwblist@olympus.net Port Ludlow, WA, USA
[about occasionally exhausting file descriptors...]
"JWB" == John W Baxter <jwblist@olympus.net> writes:
JWB> We haven't moved to either Mailman 2.1 or Exim 4 (on the
JWB> Mailman machine) yet.
JWB> But...we are seeing a Python-based web dynamic page server
JWB> (not Zope...in-house) leaving open files behind with a fairly
JWB> new Python.
JWB> We've temporized by having a monitor which does a suitable
JWB> lsof and counts the relevant open files...killing and
JWB> restarting that server when the count reaches 1000.
JWB> I'll pass along to the (really sharp) guy who is working on
JWB> that problem that you're seeing something at least vaguely
JWB> similar. We've been operating on the theory that the problem
JWB> is in our code, but...perhaps not?Possibly not, although I don't recall seeing anything on the Python lists about it. I'm running Mailman (both 2.0.10 and 2.1b2) on Python 2.1.2. I should probably upgrade to 2.1.3. However I never saw the problem until we upgraded to Exim 4. OTOH, we also turned on SpamAssassin full-bore about the same time, so there are lots of variables in this equation <wink>.
I haven't seen the problem in at least a week, so who knows? We're certainly catching lots of spam! Greg Ward should be back online any time now, so he probably won't have time to look at this until he catches up (he's our Exim guru).
-Barry
At 0:46 -0400 5/6/2002, Barry A. Warsaw wrote:
[about occasionally exhausting file descriptors...]
"JWB" == John W Baxter <jwblist@olympus.net> writes:
JWB> We haven't moved to either Mailman 2.1 or Exim 4 (on the JWB> Mailman machine) yet.
JWB> But...we are seeing a Python-based web dynamic page server JWB> (not Zope...in-house) leaving open files behind with a fairly JWB> new Python.
JWB> We've temporized by having a monitor which does a suitable JWB> lsof and counts the relevant open files...killing and JWB> restarting that server when the count reaches 1000.
JWB> I'll pass along to the (really sharp) guy who is working on JWB> that problem that you're seeing something at least vaguely JWB> similar. We've been operating on the theory that the problem JWB> is in our code, but...perhaps not?
Possibly not, although I don't recall seeing anything on the Python lists about it.
I think our problem--now seemingly solved by a change in our code--is unrelated to the Mailman problem. Unfortunately, I'm not the one who made the change, and I don't know the details.
Sorry for the false alarm (or hope, whichever it was).
--John
John Baxter jwblist@olympus.net Port Ludlow, WA, USA
On Fri, Apr 19, 2002 at 06:04:03PM -0400, Barry A. Warsaw wrote:
MM> I'll probably also contribute a small script that watches the MM> number of messages in the mailman queue, and sends a warning MM> if there are more than X (meaning that you have some serious MM> backlog, or some other problem)Which reminds me, how's your performance been with Exim4? We're seeing a lot of weird stuff happen that wasn't happening with Exim3, specifically, we seem to exhaust our open file limit about every 3rd or 4th day. It's so bad that Mailman will throw a traceback indicating it couldn't import a module (which is presumably because Python couldn't open the module file to read from). I've seen this
I haven't yet switched any of my major sites to exim 4 because I had a rather hacked up exim 3 (improved error messages and logs to deal with all the crap and misconfigured servers out there), and this came in too late for Philip to put it in exim 3, so I have to redo it for exim 4 and haven't had the time to, yet. See the two diffs here if you're curious: ftp://ftp.vasoftware.com/pub/people/merlin/exim-3.31-woody-99.1/
Being on the exim list (also I sometimes have to scan it due to the traffic), I don't remember reading anything like this. I did experience problems with exim eating all the filehandles on some linux servers (exim 3), but that was due to a bug with the solar designer secure linux kernel patch for linux 2.2.x If you're not running that buggy linux kernel (which was in linux mandrake), I don't know why you're having this problem.
This should probably be asked on the exim list (exim-users@exim.org)
Marc
Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
participants (3)
-
barry＠zope.com -
John W Baxter -
Marc MERLIN