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

[Rich Johnson]

On Mar 6, 2006, at 12:44 AM, Msquared wrote:

> On Fri, Mar 03, 2006 at 01:39:18PM -0800, Mark Sapiro wrote:
>
>> I.e, for the initial cut, split the lists/<listname> structure into
>> lists/<hostname>/<listname> and similarly for archives/private and
>> archives/public.
>
> Just a thought on this: might it be better to mangle the directories
> like so:
>
>   <hostname>/lists/<listname>
>   <hostname>/archives/<listmame>
>   etc
>
> so as to group things on a per-host basis?  One reason for doing so is
> that it (to me) makes more sense especially if you are hosting many
> domains that are not related or are different clients, etc.  It  
> simplifies
> the view of things from a per-host perspective.
>
> Perhaps even this:
>
>   <hostname>/<listname>/list
>   <hostname>/<listname>/archive
>   etc
>
> Even better, perhaps make it configurable.  :o)
>
> Regards, Msquared...
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-users% 
> 40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman- 
> developers/rjohnson%40dogstar-interactive.com
>
> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py? 
> req=show&amp;file=faq01.027.htp

I'll second this!

In general I object to co-mingling domain specific data.  it was the  
main motivation for my initial post.  I'm glad it triggered a bit  
more discussion that I expected. :-)

I'd encourage all to consider also:
  - domains are likely to have different requirements and/or be  
separately administered.
  - The storage format is not necessarily a file-system.  (as other  
discussions have indicated)
  - There's even an argument that storage format may vary between  
lists in a single domain.

In any case we have:
   archives <= f(domain,list,fmt)
   list <= f(domain,list, fmt)

How about a macro capability with $hosthame and $listname (ala Exim's  
$local_part, $domain) for filesystem storage?
One could specify:
     LIST_DATA_DIR = /var/lib/mailman/%hostname/lists
or
     LIST_DATA_DIR = /var/vdomains/%hostname/mailman/lists

in the config file according to your system/site conventions.

Another, more configurable, mechanism would be implementing  
''repository'' objects (initially implemented for filesystem  
storage):  These ''repositories'' would be indexed by ''hostname''.   
Their specification could be modeled after Apache's <VirtualHost>.   
To wit (assuming a way to interpret this snippit):
<VirtualHost  low-volume.tld>
     ArchivesRepository  filesystem
     ListsRepository         filesystem
     FilesystemRoot       /var/vdomains/low_volume/mailman
</VirtualHost>

<VirtualHost  high-volume.tld>
     ArchivesRepository  filesystem
     ListsRepository     database
     DatabaseType      Postgres
     FilesystemRoot     /var/vdomains/high_volume/mailman
     DB_info    mailman_db/mailman_usr/mailman_dbpwd
  </VirtualHost>
-----------------

Or even (tying these two together):

FilesystemRoot   /var/vdomains/%hostname/mailman
DatabaseType  postgres
DB_info          mailman-db/db-user/db-pwd
<VirtualHost low-volume.tld>
   ArchivesRepository  filesystem
   ListsRepository  filesystem
</VirtualHost>
<VirtualHost high-volume.tld>
   ArchivesRepository filesystem
   ListsRepository database
</VirtualHost>

--rich