[Mailman-Developers] Virtual Domains Redux (w proposal)

[Hans Ulrich Niedermann]

Barry Warsaw <barry at python.org> writes:

> Also, now that SF provides Subversion support, I very strongly want to
> migrate to it.  Among many other advantages, this will make it easier to
> create experimental branches to work on things like this.

Is there a time schedule for migration SVN, and would I get to play
with a branch there? :) I think my vhost branch is ready to be turned
into an experimental SVN branch.

I would first start on MM 2.2 and introduce the necessary abstractions
for file locations and the like, without changing the actual
behaviour. Once those abstrations are in place, I would then build the
vhost branch on that and thus make the vhost patch much smaller and
easier to comprehend.

Even if you do not want my vhost changes in official Mailman, those
abstractions could still be beneficial for both official Mailman and
for independent maintenance of a vhost branch.



The following is a more detailed list which shows the current state of
the vhost branch. It is not complete yet (there will still be a number
of issues to solve, and I will do so), but the basics are there:

  * Support for three list types:
     1. site wide lists without "postfix style virtual hosting":
         - internal_name()=="foo", like in 2.1.7)
         - uses the DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST
     2. site wide lists with "postfix style virtual hosting":
         - internal_name()=="fox", like in 2.1.7
         - "fox" here conflicts with site wide "fox" even in case of
           different host_name
         - uses special email_host and (possibly) url_host
     3. vhost lists
         - internal_name()=="foo at bar" (new in vhost branch)
         - no conflicts with site-wide "foo" or vhost list "foo at bleh"
         - requires registration of the url_host<->email_host relation in
           mm_cfg (cf. VIRTUAL_HOSTS, add_virtualhost()) by the site
           admin
    Note: Type 2 lists may be migrated to type 3 lists, so I have not
          tested that type 2 lists work all that well. If we drop type
          2 lists altogether, that work would have been in vain, so
          I'm not very much concerned about them. The architecture
         itself does not prevent their continued use.

  * Web and E-Mail templates produce the expected results.

  * The Web interface works as expected, as far as one can tell
    without executing an automated test with complete coverage:
     - (un)subscribing to lists works
     - administrating the list settings works
     - moderating postings works
    The URL space looks like this (for the example lists from above):
      http://lists.site-wide/listinfo/foo
      http://lists.site-wide/listinfo/fox
      http://lists.bar/listinfo/foo
      http://lists.bleh/listinfo/bleh
    Possible issues I don't care about on my installation:
     - There is no single web site which lists all lists.
     - All lists using the same url_host must use the same
       email_host.
     - You can/must use a single Apache <VirtualHost> for all lists.*
       URLs. (They do necessarily have to be called "lists.*").
     - You cannot have different basic URLs for different url_hosts,
       i.e. integration into existing websites is
       difficult/impossible.

  * Command line list creation works.

  * Sending mail to site wide lists and vhost lists works.

  * Generate proper aliases and virtual aliases for Postfix.

A few things are still to do:

  * Introduce the role of a vhost-domain admin between the site admin
    and the list admins. This requires per vhost-domain storage
    modifiable by the vhost-domain admin which we do not have. (The
    vhost-domain admin should be able to modify his password, right?)

  * Enforce the requirement of one mailman at vhost-domain list per
    vhost-domain.

  * Should we migrate the site wide lists with "postfix style virtual
    hosting" to vhost lists? I have not done this yet in order to
    avoid additional work in the proof-of-concept phase.

  * Backing out unnecessary stuff introduced while getting to know the
    code and generally clean up stuff.

  * CGI list creation/removal do not work yet.

  * ...

If you want to examine the vhost branch yourself, here are a number of
links:

Current patch against mailman-2.1.7 with the 20060114 patch:
    http://nix.lauft.net/mailman/mailman-2.1.7-20060114-to-vhost-current.patch
The README.VHOST containing more text on issues and solutions:
    http://nix.lauft.net/mailman/README.VHOST
The overview page:
    http://nix.lauft.net/mailman/
Cogito/Git repository:
    http://git.n-dimensional.de/mailman-virtualhost.git/

Gruß,

Hans Ulrich Niedermann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060310/ea01d97c/attachment.pgp