On Wed, Jun 03, 1998 at 04:08:03AM -0400, Michael McLay wrote:

Is the install script for the next release going to include automatic creation of directories using autoconfig.

Yes... thank Barry for that!

I'm having some trouble do to the odd setup of our servers. The sendmail program is running on a system that is separate from the www server.

When the command "/home/mailman/mailman/mail/wrapper post gencam" is run by sendmail it tries to archive the files on a disk that is on a different system and, if I understand correctly, this can't be done because setuid won't work across NFS mounts.

Hmm... So web based files and mail based (data) files need to have seperate configurable directories.

BTW, I was thinking about how to do SMTP and httpd on 2 seperate machines w/o NFS, and the easiest way is to run Mailman on the machine w/ the web server, and have sendmail aliases use rsh to run programs :) We should consider more efficient strategies, though, because I'm sure that people will want to do this sort of thing often.

I really like the look of mailman and I've read through many of the scripts. It is much easier on the eyes than Majordomo. The one conceptual problem I'm having with understanding the product is the interactions between the mailman user and the deamons. The permissions setting for mailman files are not obvious. Which files must be writable by "nobody" and which must be writeable by "mailman". Mailman seems to be in the middle between two deamons and a little more help in understanding the interactions would be appreciated. For instance, MAILMAN_DIR/lists/LISTNAME/config.db seems to require both mailman and nobody to have write permission.

Hmm, all of these files should be owned by Mailman. However, both sendmail and cgi processes may need to modify these data files. So when a mail or web request comes in, we set the SUID bit. Hmm, if SUID doesn't work across file systems, you may have to decide that mail commands don't work, unless you mirror the list data file across systems, because both mail commands and list commands can be used to subscribe, change options, etc.

Has bundling mailman as a package been considered? some of the mm_X.py files look like good candidates to be hidden inside a package.

It's slowly happening, yes. Barry's done a lot of work towards that end.

Mike,

A lot of your concerns will be addressed with the next release. In particular:

...

...

...

...

"MM" == Michael McLay <mclay@nist.gov> writes:

MM> This would keep the data separated from the software.  The
MM> installation instructions would have to be changed to add the
MM> lists, locks, and templates directories to HOME_DIR.

Much of this is going to change, because...

MM> Is the install script for the next release going to include
MM> automatic creation of directories using autoconfig.

Yes! The installation directory can now be completely separate from the source directory. Standard GNU configure options --prefix and --exec_prefix can be used (although the latter doesn't make a lot of sense). Everything gets installed relative to $prefix and all the paths are set up correctly to deal with this.

I've also rearranged where some of the files get installed. Eventually, I'm going to reorganize the source tree so it better reflects what the install tree looks like, but that'll come later (since it involves manually munging the CVS repository). I hope the install process will be much more straight forward in the next release. John's been debugging my autoconf stuff, so that gives me a lot more confidence :-)

MM> I'm having some trouble do to the odd setup of our servers.
MM> The sendmail program is running on a system that is separate
MM> from the www server.

I think John's move away from sendmail, toward SMTP delivery will alleviate much of this problem.

MM> When the command "/home/mailman/mailman/mail/wrapper post
MM> gencam" is run by sendmail it tries to archive the files on a
MM> disk that is on a different system and, if I understand
MM> correctly, this can't be done because setuid won't work across
MM> NFS mounts.

In the next release, nothing will have to be setuid [*]. I've reworked the permissions so that anything that needs write permission is set-gid, which I think does work across NFS mounts (please correct me if I'm wrong).

MM> I really like the look of mailman and I've read through many
MM> of the scripts.  It is much easier on the eyes than Majordomo.

Yes!

MM> The one conceptual problem I'm having with understanding the
MM> product is the interactions between the mailman user and the
MM> deamons.  The permissions setting for mailman files are not
MM> obvious.  Which files must be writable by "nobody" and which
MM> must be writeable by "mailman".  Mailman seems to be in the
MM> middle between two deamons and a little more help in
MM> understanding the interactions would be appreciated.  For
MM> instance, MAILMAN_DIR/lists/LISTNAME/config.db seems to
MM> require both mailman and nobody to have write permission.

I ran across the same problems. Using setgid scripts has solved most of this for me.

MM> Has bundling mailman as a package been considered? some of the
MM> mm_X.py files look like good candidates to be hidden inside a
MM> package.

Already done. Actually, the mm_*.py files get installed into $prefix/Mailman, and there's a __init__.py file under there, so it's already packagized. Something to do in the future (IMO), is to get rid of the mm_ prefix on the files, and fix the imports to assume packagization.

-Barry