[Mailman-Developers] Welcome To "Mailman-Developers"!

[Barry A. Warsaw]

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