![](https://secure.gravatar.com/avatar/6879e6c0bd371aaa1ddfa4c6a1d2bbf9.jpg?s=120&d=mm&r=g)
Ok, this is really 2 messages chained together...it seems John is soon to be a dad (or maybe a dad again, not sure actually :), so he's a little busy :) Any assistance is _greatly_ appreciated...the other ACM guys kept whining because the list is down, so I just set up a temp alias to quiet them until I get this sorted out :)
Is it supposed to be the case where you have to be root to create a new list? I thought that in my 1.0b4 install, I had created new lists as cklempay...but if I do it as anything other than root now (with b5), I get this:
[mailman@chimera bin]$ newlist test Enter the email of the person running the list: cklempay@acm.jhu.edu Enter the initial list password: snoop Traceback (innermost last): File "/home/mailman/bin/newlist", line 133, in ? raise SystemExit(main(sys.argv)) File "/home/mailman/bin/newlist", line 83, in main newlist.Create(list_name, owner_mail, pw) File "/home/mailman/Mailman/MailList.py", line 518, in Create Utils.MakeDirTree(os.path.join(mm_cfg.LIST_DATA_DIR, name)) File "/home/mailman/Mailman/Utils.py", line 276, in MakeDirTree os.mkdir(made_part, perms) os.error: (13, 'Permission denied') [mailman@chimera bin]$
I don't know if this is the way it is supposed to be and maybe I had it working before only because maybe I had messed up some permissions...
I had been having a LOT of problems getting it to let me access any of the pages (all of the logs turned up 'Premature end of script headers' or in some configurations I'd get a Internal Server Error). In my current state, I can view www2.acm.jhu.edu/mailman/listinfo
but if I su to root and do a newlist to create a test list, I get this if I try to access www2.acm.jhu.edu/mailman/admin/test :
We're sorry, we hit a bug!
If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks!
Traceback:
Content-type: text/html
We're sorry, we hit a bug!
Mailman experienced a very low level failure and could not even generate a useful traceback. Please report this to the Mailman administrator at this site.
I'm not sure, but I thought I remembered someone mentioning something like this earlier today too.
One other quick (and sort of unrelated question)...I just recursively zipped up my /home/mailman/lists subtree before killing b4...since my aliases are still in place (didn't touch those), can I just extract them to their original places and have it work? Or does Mailman keep other administrative data about that it won't have for these lists if I create them that way?
---next msg----
![](https://secure.gravatar.com/avatar/ab1c33fc0fd591a0ea174155233a6a51.jpg?s=120&d=mm&r=g)
Corbett,
I suspect all your problems are related to permission or ownership problems. You installed 1.0b5 on top of an earlier installation didn't you? Earlier versions weren't quite as strict on perm/ownership (esp. group ownership) as 1.0b5 -- but they had other problems. BTW, you followed the README note about moving your list template files right?
Please look at your installed directory (e.g. $prefix). You want to make sure all the files are group owned by the `mailman' group, and that all directories and files are writeable by group. Further, be sure that all directories have the group sticky bit set (so new files will inherit the right group owner).
You want to in particular, make sure lists/yourlist/config.db is group writeable, etc.
If all that looks okay, but still doesn't work, then I might suggest trying to re-install Mailman 1.0b5 into a fresh location. Re-run configure with a different --prefix. Once you've done the new install, try creating a test list under the new location (you might need to set up your Web server to include a second ScriptAlias). If this test list works, then you should be able to copy your existing list subdirs to the new location (again, watching very carefully group write permission and ownership). Now your old lists should work from your new URLs.
-Barry
![](https://secure.gravatar.com/avatar/6879e6c0bd371aaa1ddfa4c6a1d2bbf9.jpg?s=120&d=mm&r=g)
Corbett,
I suspect all your problems are related to permission or ownership problems. You installed 1.0b5 on top of an earlier installation didn't you? Earlier versions weren't quite as strict on perm/ownership (esp. group ownership) as 1.0b5 -- but they had other problems. BTW, you followed the README note about moving your list template files right?
Yeah, I thought that the install over was maybe causing me some headaches...so I did a nice rm -rf on my mailman dir and killed the user, and started over from scratch. All of the reported problems (from the previous posting) were encountered from this clean 1.0b5 install.
Please look at your installed directory (e.g. $prefix). You want to make sure all the files are group owned by the `mailman' group, and that all directories and files are writeable by group. Further, be sure that all directories have the group sticky bit set (so new files will inherit the right group owner).
Yeah, they appeared to be...and to make sure, I just went to /home and did
chmod -R g+w mailman chmod -R g+s mailman
After doing this, I pointed Netscape at http://www2.acm.jhu.edu/mailman/listinfo (as well as www2.acm.jhu.edu/mailman/listinfo/test -- I created this list as per the install)...and both gave me this now-familiar page:
We're sorry, we hit a bug!
If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks!
Traceback:
Content-type: text/html
We're sorry, we hit a bug!
Mailman experienced a very low level failure and could not even generate a useful traceback. Please report this to the Mailman administrator at this site.
You want to in particular, make sure lists/yourlist/config.db is group writeable, etc.
I killed my b4 install, but before I did, I recursively zipped up my lists subtree. So are you saying that as long as the permissions on them are right, I can just unzip them back to their place and my old lists will live once again? (all of the aliases are still active from them) I haven't tried this yet...(as I was trying to sort of these regular problems first)
Just in case you spot anything odd, I'm going to send my ls -l -R /home/mailman your way (just to you...don't want to spam the list with that...)
CK
![](https://secure.gravatar.com/avatar/ab1c33fc0fd591a0ea174155233a6a51.jpg?s=120&d=mm&r=g)
Corbett,
Everything looks okay to me, and I just did a fresh install, as root, from the 1.0b5 tarball. Then I created a dummy list and had no problem viewing the list-of-lists and the specific list info page. Note that I am running this in a Solaris 2.6 system, what OS are you using? We've had one other report of something similar happening on Linux (so I wonder if some OS problem could happening).
Since I can't reproduce the problem on my end, I'm going to need your help. We have trace through the driver script to see where it's crapping out. Here's a version that does some very simple print-style tracing to /tmp/mailman.log. Can you substitute this for scripts/driver and see if it gives you a clue as to what is failing?
-Barry
#! /usr/bin/env python # # Copyright (C) 1998 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.
# Useful for debugging. When an error occurs, this attaches the file name to # the exception string and re-raises (using the bogus Python 1.5 semantics) # this may be unnecessary in Python 1.5.2
## realopen = open ## def open(filename, mode='r', bufsize=-1, realopen=realopen): ## try: ## return realopen(filename, mode, bufsize) ## except IOError, e: ## strerror = e.strerror + ': ' + filename ## e.strerror = strerror ## e.args = (e.args[0], strerror) ## # Python 1.5 ## import sys ## raise e, None, sys.exc_info()[2] ## # Python 1.5.1 ## #raise ## import __builtin__ ## __builtin__.__dict__['open'] = open
# This standard driver script is used to run CGI programs, wrapped in code # that catches errors, and displays them as HTML. This guarantees that # (almost) any problems in the Mailman software doesn't result in a Web server # error. It is much more helpful to generate and show a traceback, which the # user could send to the administrator, than to display a server error and # have to trudge through server logs.
# Note: this isn't 100% perfect! Here are some things that can go wrong that # are not caught and reported as traceback-containing HTML: # # - This file could contain a syntax error. In that case, you would indeed # get a Web server error since this file wouldn't even compile, and there's # no way to catch that. # # - The sys module could be royally screwed. Either we couldn't import it, or # it didn't have a sys.stderr attribute. Both those would indicate serious # problems in the Python installation. These won't generate Web server # errors, but neither will they give meaningful tracebacks. # # - We couldn't import the traceback module, or traceback.print_exc() # failed. Same diagnosis and effect as with sys being broken. # # I consider all these pretty unlikely. Note that it is also possible that # the environment variables wouldn't be printed, perhaps because os couldn't # be imported or there was some problem with os.environ. Again, not likely.
def run_main(): try: # insert the relative path to the parent of the Mailman package # directory, so we can pick up the Utils module fp.write('import os\n') import os # sys gets imported at module level below fp.write('sys.path.insert()\n') sys.path.insert(0, os.pardir) # map stderr to a logger, if possible fp.write('import StampedLogger\n') from Mailman.Logging.StampedLogger import StampedLogger fp.write('import MultiLogger\n') from Mailman.Logging.MultiLogger import MultiLogger fp.write('instantiating logger\n') logger = StampedLogger('error', label='admin', manual_reprime=1, nofail=0) fp.write('instantiating multi\n') multi = MultiLogger(sys.__stdout__, logger) # The name of the module to run is passed in argv[1]. What we # actually do is import the module named by argv[1] that lives in the # Mailman.Cgi package. That module must have a main() function, which # we dig out and call. # fp.write('should now get normal error reporting\n') scriptname = sys.argv[1] # See the reference manual for why we have to do things this way. # Note that importing should have no side-effects! pkg = __import__('Mailman.Cgi', globals(), locals(), [scriptname]) module = getattr(pkg, scriptname) main = getattr(module, 'main') try: main() except SystemExit: # this is a valid way for the function to exit pass except: print_traceback(logger, multi) print_environment(logger)
def print_traceback(logger, multi):
print """
Content-type: text/html
<p><h3>We're sorry, we hit a bug!</h3>
<p>If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks!
<h4>Traceback:</h4> <p><pre> """ logger.write('[----- Traceback ------]\n') try: import traceback # in normal situation, this will get logged to the MultiLogger created # above, which will write the data to both the real live stdout, and # the StampedLogger traceback.print_exc(file=multi) except: multi.write('[failed to get a traceback]\n') print '\n\n</pre>'
def print_environment(logger):
try:
import os
print '''
<p><hr><h4>Environment variables:</h4>
<p><table> <tr><td><strong>Variable</strong></td> <td><strong>Value</strong></td></tr> ''' logger.write('[----- Environment Variables -----]\n') for varname, value in os.environ.items(): print '<tr><td>', varname, '</td><td>', value, '</td></tr>' logger.write('\t%s: %s\n' % (varname, value)) print '</table>' except: print '<p><hr>[environment variables are not available]'
try:
fp = open('/tmp/mailman.log', 'w+')
fp.write('=====\nimport sys\n')
import sys
try:
fp.write('run_main()\n')
run_main()
fp.write('done.\n')
finally:
# this is probably not strictly necessary since the script is exiting
# soon anyway
sys.stderr = sys.__stderr__
except:
# Jeez, we couldn't even import sys, or sys didn't have a stderr
# attribute!
print """
Content-type: text/html
<p><h3>We're sorry, we hit a bug!</h3>
Mailman experienced a very low level failure and could not even generate a useful traceback. Please report this to the Mailman administrator at this site. """
![](https://secure.gravatar.com/avatar/6879e6c0bd371aaa1ddfa4c6a1d2bbf9.jpg?s=120&d=mm&r=g)
Ok, I'll play with that sometime tonight..I have to split now for a few hours. (my TA hours coming up in a bit here)
The system is a Red Hat 5.1 system.
Corbett J. Klempay Quote of the Week:
http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places,
character in the full current of
human life."
PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1
participants (2)
-
Barry A. Warsaw
-
Corbett J. Klempay