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

Rich Johnson rjohnson at dogstar-interactive.com
Wed Mar 1 04:56:32 CET 2006


AKA, "The Perennial Issue" (TPI)

I've been looking at this for a while; I've scanned the archives; and  
I've perused the code (well a chunk of it anyway).
I realize that mailman _sort of_ supports virtual domains, but  
doesn't _really_ support virtual domains.

As I look at the situation from the perspective of a sysadmin or ISP,  
there are two aspects that really bother me:
  - comingling of data from separate virtual domains
  - ''site'' password shared between virtual domains

 From my perusals I think what I'm really asking for is a per-domain  
assignment of VAR_PREFIX to segregate the domain's data.  If so, the  
question becomes how to achieve it.

-------------------------------

Here's the proposal:
  -- add a configfile option to the mailman utilities.

That's it!
. . . . . . . . . . . . .

Advantages include:
  - heavy lifting is limited to mm_cfg.py (or Defaults.py).  I  
propose adding a "configure( filename)" function to incorporate the  
configfile
  - VAR_PREFIX could be defined on a per-domain basis;  
mm_cfg.configure() would have to be prepared for this.
  - multiple instances of mailman utilities no longer required.
  - transparent to existing configurations.
  - ability to manage any of the mm_cfg parameters on a per-domain  
basis.

Disadvantages include:
  - changes woulld be pervasive, and this cannot be underestimated.   
However, most changes are either an additional getopt elif clause or  
insuring that the configfile specification is propagated  
appropriately.  For the most part, these changes are  straightforward.
- all utility invocations for a given domain must use the same  
configfile.  This is no improvement over, but not more difficult  
than,  managing a separate mailman installation for each domain.

Other comments:
  - an Exim ''mailman_vdom_transport'' can provide domain specific  
config file to the mail wrapper.
  - httpd rewrite rules could generate domain (vhost) sepcific  -- 
config=<confile>  args to listinfo etc.
  - I'm not sure about mailer requirements for Postfix, qmail, etc.
  - a qrunner for each domain will be required; as is the case for  
multiple installation copies.

--------------------------------

Expected usage of the --config option for virtual domain processing  
would be:
(this example is targeted for a Debian system running Exim4/Apache2  
where all domain specific data for virtual domain "domain1.tld" is  
kept in /var/vdomains/domain1.tld.))

Each virtual domain supplies a configfile.  This config file might be  
a 1 liner like:
      VAR_PREFIX = /var/vdomains/domain1.tld/mailman/data

or it might contain other specializations as well.

The various system utiltiies would dereference the configfile for the  
domain before invoking mailman utilities.  For example (may contain  
typos):

      /etc/crontab might include lines like:
        0 9 * * * list [ -x /usr/lib/mailman/cron/disabled ] && /usr/ 
lib/mailman/cron/disabled --config=/var/domains/domain1.tld/mailman.conf

    An exim transport might contain a line like:
       command = MAILMAN_WRAP --config=/var/vdomains/$domain/ 
mailman.conf \
         '${if def:local_part_suffix \
         {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
         {post}}' \
         $local_part

    An apache2 virtual host would contain directives like
       <Location /cgi-bin/>
	        RewriteEngine on
  		RewriteRule  ^listinfo$  listinfo?--config=/var/vdomains/ 
domain1.tld/mailman.conf
        </Location>
      or
        ScriptAliasMatch ^/mailing_lists/(.*)   /usr/lib/mailman/cgi- 
bin/$1?--config=/var/vdomains/domain1.tld/mailman.conf

where the <configfile> contains my_cfg.py segments.

------------------------

Comments?  Advice?  Reactions of Horror?  Am I WAAAY off base?

Has this approach been previously considered and rejected?

FWIW, I've worked out  a _basic_ implementation for mm_cfg.configure 
(filename) and it's use by the cron utilities and would like to get  
some reaction before going any further.

--rich




More information about the Mailman-Developers mailing list