Either I screwed up when I followed the installation instructions or else the file ownership set by "make install" incorrectly set the group of the executables in $prefix/cgi-bin to that of the super user. In order for the scripts to work the group had to be manually set to "mailman".
I accidentally created a copy of $prefix/data/pending_subscriptions.db with the wrong group ownership which caused the subcribe script to fail with an "Internal Server Error" The script failed because of a file access permission error. In order to find the problem I did some code reorganization. The $prefix/scripts/subscribe file was moved to $prefix/Mailman/subscribe.py and the attached file was put in place of the $prefix/scripts/subscribe file.
This change should also reduce the script execution time slightly because the longer script will be compiled to a .pyc file. I would like to wrap all the other file in the $prefix/scripts/ in the same manner. Once this is done the common.c program can be modified to insert the PREFIX directory into the path rather than the MODULEDIR. This will eliminate the need for the paths module in each of the scripts and it would eliminate the need for the following lines in my new wrapper script:
sys.path.remove('/usr/local/mailman/Mailman')
sys.path.insert(0, '/usr/local/mailman')
This generalized error wrapper would also eliminate some redundant error reporting code in admin.
John, what do you think of removing the mm_ prefix from the module names? It's not really needed now that everything is pushed into the Mailman package.
----------------------- $prefix/scripts/subscribe ---------------------
#! /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.
"""Process listinfo form submission, ie subscriptions or roster requests."""
import sys from Mailman.subscribe import * try: sys.path.remove('/usr/local/mailman/Mailman') sys.path.insert(0, '/usr/local/mailman') from Mailman.subscribe import *
except SystemExit: pass
except: print "Content-type: text/html\n"
print "<p><h3>We're sorry, we hit a bug!</h3>\n"
print "If you would like to help us identify the problem, please "
print "email a copy of this page to the webmaster for this site"
print 'with a description of what happened. Thanks!'
print "\n<PRE>"
print sys.argv
try:
import traceback
sys.stderr = sys.stdout
traceback.print_exc()
except:
print "[failed to get traceback]"
print "\n\n</PRE>"
Nothing like following up to your own posts:-)
Michael McLay writes:
In order to find the problem I did some code reorganization. The $prefix/scripts/subscribe file was moved to $prefix/Mailman/subscribe.py and the attached file was put in place of the $prefix/scripts/subscribe file.
This change should also reduce the script execution time slightly because the longer script will be compiled to a .pyc file. I would like to wrap all the other file in the $prefix/scripts/ in the same manner. Once this is done the common.c program can be modified to insert the PREFIX directory into the path rather than the MODULEDIR.
Why not have the install script install the package Mailman directly in the user's site-python directory? Isn't that where it belongs? Then the path manipulation doesn't have to take place at all.
This will eliminate the need for the paths module in each of the scripts and it would eliminate the need for the following lines in my new wrapper script:
sys.path.remove('/usr/local/mailman/Mailman') sys.path.insert(0, '/usr/local/mailman')This generalized error wrapper would also eliminate some redundant error reporting code in admin.
I've done a little more work on generalizing the wrapper and adding some more optional debug information. The new module Mailman.debug contains two functions. The first one prints out the trace information. The second function will print out uid and gid information and the server environment variables. I turn off the more detailed messages using a debug flag in the $prefix/script/* scripts.
If the Mailman is moved to site-python then the "import sys" statement could be deleted and the only statement inside the try block would be
from Mailman.subscribe import *
The SystemExit exception could be eliminated as well if the code in Mailman.subscribe were rearranged to eliminate the call to sys.exit().
The new arrangement also moves the debug code out of the scripts unless an exception is called. This reduces $prefix/script/subscribe file to the following:
########################## $prefix/script/subscribe ################# #! /usr/bin/env python # # Copyright (C) 1998 by the Free Software Foundation, Inc. # under the GNU General Public License See the License file in the top level # of this distribution for details.
"""Process subscribe form submission, ie subscriptions or roster requests."""
debug = 1 # turn on to enable environment parameter printing on errors import sys try: sys.path.remove('/usr/local/mailman/Mailman') sys.path.insert(0, '/usr/local/mailman') from Mailman.subscribe import *
except SystemExit: pass
except: import Mailman.debug Mailman.debug.print_trace() if debug: Mailman.debug.print_environ()
On Fri, Jun 05, 1998 at 01:31:06PM -0400, Michael McLay wrote:
Why not have the install script install the package Mailman directly in the user's site-python directory? Isn't that where it belongs? Then the path manipulation doesn't have to take place at all.
Well, currently the install portion shouldn't be done as root, and unless Mailman has access to the site-python directly, it would become necessary. I think it's a good thing to be able to install this software without having to have root access. True, unless you run an MTA like qmail, you're still going to need someone to add mail aliases for you. But we could add an optional make root-install target or something like that that would go back to using the alias wrapper, etc.
I've done a little more work on generalizing the wrapper and adding some more optional debug information. The new module Mailman.debug contains two functions. The first one prints out the trace information. The second function will print out uid and gid information and the server environment variables. I turn off the more detailed messages using a debug flag in the $prefix/script/* scripts.
Nice work on the wrapper code!
John
"MM" == Michael McLay mclay@nist.gov writes:
MM> I've done a little more work on generalizing the wrapper and
MM> adding some more optional debug information. The new module
MM> Mailman.debug contains two functions.
BTW, I *really* like this idea, Mike. I like the traceback showing up on the Web page, especially at this stage in Mailman's life.
-Barry
On Fri, Jun 05, 1998 at 12:32:32PM -0400, Michael McLay wrote:
This change should also reduce the script execution time slightly because the longer script will be compiled to a .pyc file. I would like to wrap all the other file in the $prefix/scripts/ in the same manner. Once this is done the common.c program can be modified to insert the PREFIX directory into the path rather than the MODULEDIR. This will eliminate the need for the paths module in each of the scripts and it would eliminate the need for the following lines in my new wrapper script:
One thing I'm thinking is that setenv() has portability problems, and it may be better not to use it at all.
John, what do you think of removing the mm_ prefix from the module names? It's not really needed now that everything is pushed into the Mailman package.
I think it's fine for the prefix to go away, although I would probably either like to see the files that are used as mixins to retain a prefix, or see a better directory structure, especially since now there are going to be all of these CGI scripts in the package, too: there will be a lot of files in one directory, and it won't be easy to figure out what groups with what.
John
"JV" == John Viega viega@list.org writes:
JV> One thing I'm thinking is that setenv() has portability
JV> problems, and it may be better not to use it at all.
Probably wise.
JV> I think it's fine for the prefix to go away, although I would
JV> probably either like to see the files that are used as mixins
JV> to retain a prefix, or see a better directory structure,
A better directory structure!!!! :-)
-Barry
Normal Friday catchup...
"MM" == Michael McLay mclay@nist.gov writes:
MM> Either I screwed up when I followed the installation
MM> instructions or else the file ownership set by "make install"
MM> incorrectly set the group of the executables in
MM> $prefix/cgi-bin to that of the super user. In order for the
MM> scripts to work the group had to be manually set to "mailman".
One thing the next version will have is more checking of the permissions on $prefix. If the permissions or group ownership aren't correct, configure stops. This should prevent those problems from cascading to all the other installed files.
MM> This change should also reduce the script execution time
MM> slightly because the longer script will be compiled to a .pyc
MM> file.
That may or many not really be an issue. I suspect starting up the Python interpreter for every script is the killer, rather than parsing the script files. subscribe for example is less than 200 lines of Python. Admin is certainly the longest at 856 lines.
One thing that's high on my list is to really fix the packagization of Mailman. I think given that, many things get simpler. You still need a little path hacking, but that can be done in a more portable way than even the paths.py files. And then most of the functionality in the scripts can be moved into package libraries. This will improve the modularity A LOT. I just finished doing this with a project here at CNRI and it makes a big difference.
MM> John, what do you think of removing the mm_ prefix from the
MM> module names?
This can easily happen, with no chance of name collisions, even for the mixin classes. I also want to rename some of the .py files to match the contained class names (better style). So there are several things of this nature I want to work on, but my meta question is this:
From a technical standpoint, how close to a 1.0 release are we? What
critical features are still missing (integration with Pipermail is key), and what showstopper bugs are still lurking? Should I continue to do code clean up now, or wait until after 1.0?
-Barry
On Fri, Jun 12, 1998 at 04:34:38PM -0400, Barry A. Warsaw wrote:
From a technical standpoint, how close to a 1.0 release are we? What
critical features are still missing (integration with Pipermail is key), and what showstopper bugs are still lurking? Should I continue to do code clean up now, or wait until after 1.0?
I anticipate a few more beta releases first. No one is jumping up to do the Pipermail stuff in a portable way, so that's going to delay us time wise. Locking needs to be improved a bit; it would be nice if the granularity were better. I think there's a need for more documentation before we leave beta. All password-pages should use the cookie code, AND have the extra password field for cookie-less people, which currently isn't done at all. I'd also like to move all web pages and mail messages that should be editable out into the template dirs. That's less important, though. We also need to go through and make sure all email addresses that can be entered can't be used in an insecure manner (check for |'s etc. in every address, entered from anywhere).
Also, not only would I like to see archiving back in, I also want to see it with a search engine, by default.
As for bugs, there are some on the Mailman TODO page that may or may not be current. Nothing major, though. There's one big one that's been reported and I haven't found yet. I'll send it on in another email, perhaps someone else can find it before I do.
That's what I'd like to see. And it really isn't all that much, but I'll bet it's at least a month off. Plus, we should try to have a stable beta for a few weeks before we release it as 1.0.
Oh, beyond that, we need to make sure we get all permissionsissues squared away. Pipermail's a good example of that one. Maybe Andrew should try to get it blessed as the GNU mail archiver before we bundle it? :)
John
participants (3)
-
Barry A. Warsaw -
John Viega -
Michael McLay