[Mailman-Users] Strange errors

Thu Oct 20 03:05:52 CEST 2005

Dan Szkola wrote:

>John W. Baxter wrote:
>
>>On 10/19/05 11:14 AM, "Dan Szkola" <szkola at tanis.cso.niu.edu> wrote:
>>
>>  
>>
>>>Mark Sapiro wrote:
>>>
>>>    
>>>
>>>>Dan Szkola wrote:
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>>>Patched the admin script as suggested. When I saw the error this
>>>>>morning, I emailed
>>>>>to the admin address of our test list. Here is what I got:
>>>>>
>>>>> ----- Transcript of session follows -----
>>>>>PYTHONPATH /usr/local/mailman
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>>I wouldn't have expected this, but I don't think it should matter.

A closer look reveals that this comes from the wrapper and thus is
always there.

>>>>
>>>>What do you get if you add to the patch as follows
>>>>
>>>>--- admin       2005-10-14 16:31:42.078125000 -0700
>>>>+++ admin_patched       2005-10-19 10:21:51.328125000 -0700
>>>>@@ -25,8 +25,16 @@
>>>>"""
>>>>
>>>>import sys
>>>>+from os import environ
>>>>+for env_var in environ:
>>>>+    print env_var, environ[env_var]
>>>>+for s_path in sys.path:
>>>>+    print 'before =', s_path
>>>>
>>>>import paths
>>>>+for s_path in sys.path:
>>>>+    print 'after =', s_path
>>>>+
>>>>from Mailman import mm_cfg
>>>>from Mailman import Utils
>>>>from Mailman.i18n import _
>>>>
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>   ----- Transcript of session follows -----
>>>PYTHONPATH /usr/local/mailman
>>>AGENT sendmail
>>>before = /usr/local/mailman/scripts
>>>before = /usr/local/mailman
>>>before = /usr/local/lib/python24.zip
>>>before = /usr/local/lib/python2.4/
>>>before = /usr/local/lib/python2.4/plat-sunos5
>>>before = /usr/local/lib/python2.4/lib-tk
>>>before = /usr/local/lib/python2.4/lib-dynload
>>>after = /usr/local/mailman/pythonlib
>>>after = /usr/local/mailman
>>>after = /usr/local/mailman/scripts
>>>after = /usr/local/mailman
>>>after = /usr/local/lib/python24.zip
>>>after = /usr/local/lib/python2.4/
>>>after = /usr/local/lib/python2.4/plat-sunos5
>>>after = /usr/local/lib/python2.4/lib-tk
>>>after = /usr/local/lib/python2.4/lib-dynload
>>>after = /usr/local/lib/python2.4/site-packages
>>>Traceback (most recent call last):
>>>  File "/usr/local/mailman/scripts/admin", line 42, in ?
>>>    from Mailman.Queue.sbcache import get_switchboard
>>>  File "/usr/local/mailman/Mailman/Queue/sbcache.py", line 19, in ?
>>>    from Mailman.Queue.Switchboard import Switchboard
>>>  File "/usr/local/mailman/Mailman/Queue/Switchboard.py", line 47, in ?
>>>    from Mailman.Logging.Syslog import syslog
>>>  File "/usr/local/mailman/Mailman/Logging/Syslog.py", line 22, in ?
>>>    from Mailman.Logging.StampedLogger import StampedLogger
>>>  File "/usr/local/mailman/Mailman/Logging/StampedLogger.py", line 20, in ?
>>>    from Mailman.Logging.Logger import Logger
>>>  File "/usr/local/mailman/Mailman/Logging/Logger.py", line 25, in ?
>>>    from Mailman.Logging.Utils import _logexc
>>>  File "/usr/local/mailman/Mailman/Logging/Utils.py", line 18, in ?
>>>    import traceback
>>>ImportError: No module named traceback
>>>554 5.3.0 unknown mailer error 1
>>>
>>>Oddly, the correct path statement is the only one with a trailing slash.
>>> 

This shouldn't be a problem. I tried adding the slash in my Python
2.4.1 and it didn't matter.

>>>
>>
>>
>>Have we eliminated the possibility that--due to some unfortunate
>>event--there really is no traceback module (or it can't be read)?
>>
>>What do you get from
>>ls -l /usr/local/lib/python2.4/traceback.py
>>
>>If it is there, does that file have world read permission?
>>
>>Do you have multiple Python versions installed?
>>
>>  --John
>>  
>>
>Yep. If it didn't exist or was unreadable, wouldn't the script bail under
> normal circumstances?

Yes, unless somehow it becomes unreadable and restarting sendmail makes
it readable again. That's too scary to even think about.

>Anyway, here is the output of an "ls -l /usr/local/lib/python2.4/tr*":
>
>-rw-r--r--   1 bin      bin        28935 May 27 11:59 
>/usr/local/lib/python2.4/trace.py
>-rw-r--r--   1 bin      bin        22092 May 27 12:01 
>/usr/local/lib/python2.4/trace.pyc
>-rw-r--r--   1 bin      bin        22030 May 27 12:01 
>/usr/local/lib/python2.4/trace.pyo
>-rw-r--r--   1 bin      bin        10464 May 27 11:59 
>/usr/local/lib/python2.4/traceback.py
>-rw-r--r--   1 bin      bin        11030 May 27 12:01 
>/usr/local/lib/python2.4/traceback.pyc
>-rw-r--r--   1 bin      bin        11030 May 27 12:01 
>/usr/local/lib/python2.4/traceback.pyo
>
>I have also tried copying the traceback.py file into various places that 
>make sense and I
>get the same error. I know it is getting read because it gets compiled 
>into a .pyc file.

The implications of this are also too scary to think about.

>The python 2.4.1 was compiled from source and is the only python version 
>on the box.

In a later post, you say it wasn't, but you removed the Sun Gnome
Python 2.3. I hope that fixes it, but I doubt it will.

Here's something else to try if it fails again. As the mailman user in
the /usr/local/mailman directory, give the command

python2.4 -S /usr/local/mailman/scripts/admin listname <file

where listname is the name of the list and file contains an arbitrary
rfc822-like message. It can be as simple as

---------------------------------
From: user at example.com
To: junk at example.com
Subject: test

body
--------------------------------

Except for the fact that this doesn't edit the environment passed to
the script, it is the same as invoking the script from the wrapper. If
it works, it will produce an 'unrecognized bounce' which will be
forwarded to the list owner if the option to do so is selected. If it
doesn't work, it will produce a similar output to the above, but the
key is that if it doesn't work, we'll know that the problem, even
though fixed by restarting sendmail and not by restarting Mailman,
occurs even though sendmail doesn't directly invoke the script via the
wrapper. If it does work, we'll know that it involves the script being
invoked through the wrapper.

You could then try

/usr/local/mailman/mail/mailman admin listname <file

to see if it occurs when you rather than sendmail invoke the wrapper,
but this has to be done from the group that sendmail uses, i.e., the
group that the wrapper expects to be invoked by. Otherwise, the
wrapper will complain because this is exactly the security violation
the wrapper is supposed to catch.

-- 
Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan